Настройка VPN на линуксе через графический интерфейс

[romkaromka 8]

Для настройки VPN в Linux по протоколам PPTP/L2TP есть графическая программа vpnpptp. Программа работает в различных дистрибутивах, но на данный момент поддерживаются только дистрибутивы, основанные на Mageia.

 

Сайт проекта: http://sourceforge.net/projects/vpnpptp

Исходники: http://sourceforge.net/projects/vpnpptp/files

Постить баги: http://sourceforge.net/p/vpnpptp/tickets

Инструкция на русском языке: http://sourceforge.net/projects/vpnpptp/files

Инструкция на украинском языке: http://sourceforge.net/projects/vpnpptp/files

Алгоритм работы программы (вики): http://sourceforge.net/p/vpnpptp/wiki

Инструкции по сборке пакетов есть в исходниках.

 

Пакет ставится из официального репозитория Mageia, а в ряде дистрибутивов он уже предустановлен.

В инструкциях подробно с картинками описано как установить программу, как настроить локальную сеть и как поднять VPN.

 

Графически настройка VPN осуществляется мастером настройки и появляется ярлык запуска VPN на Рабочем столе, то есть наиболее близко с настройкой и пользованием в Windows.

 

В основном ошибки настройки связаны с аутентификацией, шифрование mppe в Билайне не используется, поэтому выбирать никаких опций шифрования mppe не нужно. Об этих ошибках написано как в инструкции, так и в вики.

Необходимо помнить, что refuse-chap не разрешает chap, а запрещает! Аналогично с другими опциями аутентификации.

Выявить другие ошибки настройки можно через кнопку Тестового запуска в конфигураторе, где в режиме реального времени будут отображаться логи.

Настройка для Билайна проста: необходимо лишь указать адрес vpn-сервера, логин, пароль, остальные опции часто можно оставить по-умолчанию.

 

Теперь рассмотрим как пользоваться локальными ресурсами Билайна при поднятом VPN.

Если при поднятом VPN тот или иной ресурс не работает локально, то в конфигураторе vpnpptp вписываем маршруты (см. рисунок). На рисунке зеленым подчеркнут ресурс, который мы хотим сделать локальным при поднятом VPN, например, ftp.corbina.ru. На рисунке красным подчеркнут шлюз локальной сети, а синим подчеркнут сетевой интерфейс. Теперь при поднятом VPN ресурс ftp.corbina.ru будет доступен локально.

route add -host ftp.corbina.ru gw шлюз_локальной_сети dev сетевой_интерфейс

(вместо ftp.corbina.ru можно указать ip-адрес, который можно определить через команду ping -c1 ftp.corbina.ru)

(аналогично для p2p.corbina.net если Вы пользуетесь файлообменом через хаб p2p.corbina.net)

На примере Mandriva 2010.0 i586 рассмотрим как пользоваться ресурсом ftp.corbina.ru.

Найдите на ftp.corbina.ru свой дистрибутив вплоть до архитектуры (на рисунке показан браузер firefox с открытой страницей ftp://ftp.corbina.ru/mandriva/official/2010.0/i586/). Зайдите в Меню->Утилиты->Системные->Настройка компьютера->Управление программами->Настройка источников установки/обновления ПО->Файл->Добавить пользовательский источник.

Выберите тип источника: Сервер HTTP

Название источника укажите любое

Установите галочку "Создать источник для всего дистрибутива"

URL: укажите свой дистрибутив на ftp.corbina.ru вплоть до архитектуры, например, ftp://ftp.corbina.ru/mandriva/official/2010.0/i586/

Нажмите ОК.

Теперь установите все галочки на всех пунктах, кроме пунктов, содержащих слова debug, testing.

Нажмите ОК.

Теперь через vpnpptp Вы сможете выйти в интернет, но при этом в linux устанавливать программы с ftp.corbina.ru на локальной скорости.

Изменено 25 сентября 2015 пользователем romkaromka

[romkaromka 8]

Для пакета vpnpptp доступна инструкция: http://sourceforge.net/projects/vpnpptp/files

Во вложении инструкция, доступная локально.

Help_ru.pdf.gz

Изменено 25 сентября 2015 пользователем romkaromka

[VerDante 1]

Спасибо

Изменено 2 декабря 2009 пользователем VerDante

[romkaromka 8]

Возможности версии 0.0.3

* 1) проверка корректности вводимых пользователем в конфигураторе данных.

* 2) разрешено пользователям самим задавать время дозвона (максимальное время ожидания ответа провайдера на звонок при отсутствующем соединении) в пределах от 5 до 255 сек.

* 3) разрешено пользователям самим задавать время реконнекта (время реакции на пропадание соединения, время контроля за состоянием поднятого соединения) в пределах от 1 до 255 сек.

* 4) разрешены 10 сетевых карт от eth0 до eth9.

* 5) теперь для mtu разрешен диапазон [576..1460..1492..1500], рекомендуется 1460.

* 6) поправлен недочет автоматического определения сетевого интерфейса и шлюза локальной сети в конфигураторе, если пытаться настроить vpn на ethN, где 0<N>10 (то есть если сетевой интерфейс отличен от eth0, то есть имеет меньший приоритет).

* 7) реконнект теперь опционален, на выбор пользователя предложено 2 варианта:

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

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

* 8) теперь сколько бы в системе не было сетевых интерфейсов, программа бережно обращается с ними со всеми, сама их не задевает, а если их задевает сам процесс pppd (а именно он их и задевает, так как самостоятельно выполняет скрипты ip-up, ip-down), то программа исправит за ним его ошибки, поэтому в любой момент времени сеть на чем-нибудь будет поднята (если только реально есть на чем поднять сеть).

* 9) появилась возможность автоматического переключения на другого провайдера, идущего в порядке очередности по приоритету сетевого устройства, на котором он был закреплен.

* 10) улучшилась индикация NetApplet, стала быстрее, индикация ponoff полностью с ней синхронна.

* 11) падение ppp0 при аварии теперь определяется и обрабатывается мгновенно (кроме случаев падения vpn-сервера - обработка теоретически с задержкой и dns-серверов неизвестно как обрабатывается).

* 12) попытка вновь поднять vpn происходит мгновенно как только сетевушка поднялась после аварии или отключения.

* 13) с легкостью временно переключается на другого провайдера и также легко переключается обратно.

* 14) сетевые карты больше не отключаются вообще сколько аварий не делай.

* 15) необходимость в базе учета интерфейсов отпала и сеть отдана на самостоятельное течение системы, которая неплохо с этим справляется.

* 16) ppp0 полностью привязан к конкретной сетевой карте, на которой он был настроен.

* 17) скрипт /etc/ppp/ip-down.d/ip-down теперь пустой, в него ничего не пишите, вместо него можно будет использовать скрипт /opt/vpnpptp/ip-down - в нем и будут теперь маршруты при отключении ppp0; на практике скрипт /opt/vpnpptp/ip-down будет выполняться лишь при выходе из программы, по есть по кнопке Выход (у нас он пустой за неимением таких маршрутов).

* 18) самое главное: программа полностью исправила 2 бага в pppd: 1) баг, связанный с неучитыванием state сетевого интерфейса, на котором поднималось vpn, и, как следствие, нарушение целостности сетевых интерфейсов, 2) баг крайне медленной реакции на аварийную ситуацию, как следствие не учитывания того же самого state, и наша программа научилась управлять pppd как по часовому механизму.

* 19) теперь необходимы 2 Выхода из программы: с выполнением скрипта опускания и без выполнения скрипта опускания, потому что на момент выхода из программы ponoff может либо не быть аварии, а может и быть авария; то есть возвращать сеть в состояние до поднятия vpn или нет.

* 20) для тех, у кого конфигуратор отработал нормально, но vpn не поднимается из-за того, что сетевая карта не поддерживает некоторые команды (когда не поддерживаются MII запросы - но это должна быть очень древняя сетевая карта,или очень дешевая)- в этом случае в Конфигураторе поставьте галочку "Не контролировать state сетевого кабеля", но учтите, что в этом случае вы лишаетесь привязки к конкретной сетевой карте (для одной сетевой карты некритично вообще), утрачиваете скоростную индикацию и увеличиваете нагрузку на систему при обрыве связи.

 

* Примечания: Оба варианта реконнекта удобны тем, что при падении vpn, если авария не критическая, то локальная сеть на сет. устройстве, где упало vpn, должна продолжить свою работу (планирую опцию возможности отключения для этого случая и локальной сети), но если критическая, то прекратят работать и vpn, и локальная сеть, при этом начнут работать другие сетевые интерфейсы, а значит в этом случае появляется возможность автоматического переключения на другого провайдера.

* Аксиома1: сетевые интерфейсы (ethN) eth0-eth9 различаются по приоритету. Чем больше N, тем меньше приоритет у сетевого устройства. Система самостоятельно решает в какой момент времени какой сет. интерфейс будет дефолтным исходя из его приоритета и его state. Это правило одного дефолтного интерфейса (в системе может быть лишь один дефолтный шлюз).

* Имеется состояние системы А. Мы переводим его из состояния А в состояние Б посредством демона pppd. При переводе из А в Б демон pppd самостоятельно использует инструкцию АБ, а при переводе из Б в А – самостоятельно инструкцию БА. Демон pppd также самостоятельно обнаруживает падение поднятого им же vpn и при этом переводит состояние системы из Б в А через инструкцию БА. Но а что если теперь состояние интерфейса А изменилось? В этом случае демон pppd сделает грубые ошибки – это критический баг демона pppd – походу он не умеет отслеживать state.

* Решение: подсунуть демону pppd такую инструкцию БА, при выполнении которой никаких изменений не произойдет (обычную пустышку) и самостоятельно в программе обработать корректный перевод из Б в А с учетом state интерфейса А. Система же, потеряв интерфейс ppp, самостоятельно найдет ближайший подходящий интерфейс, учитывая аксиому1. От нас лишь требуется запомнить и бережно хранить инструкцию БА.

Инструкция АБ - это скрипт ip-up, а инструкция БА - это скрипт ip-down.

 

==Идеи и нерешенные проблемы конфигуратора и интерфейса управления соединениями VPN через PPTP==

* 1) нет логов соединения pppd.

решение: возможно будет добавлено.

* 2) ppp0 плохо интегрирован в NetAplet.

решение: практически он может лишь запускаться из Настройки Сети, дальнейшая интеграция зависит от разработчиков ОС мандрива.

* 3) улучшить занесение пользователем маршрутов в конфигураторе.

решение: предложить пользователю таблицу с графами host, net, netmask, gw, dev с подсказками что означает каждая графа и предложить выпадающие списки для каждой из граф с имеющимися в данной конкретной системе значениями.

* 4) не обеспечена возможность задания и одновременной работы двух и более pptp-подключений, в том числе не только на разных сетевых картах, но и на одной.

решение: идея пока преждевременная.

* 5) не обеспечена база провайдеров, для которых тест пакета прошел успешно, и установка простым выбором из списка по этой базе.

решение: найдено, возможно постепенно база будет увеличиваться, а возможно это и лишнее.

* 6) не обеспечен автозапуск vpn при старте системы.

решение: можно добавить, но смысла особого в этом нет.

* 7) недостаточно крепко закреплен в трее. в случае падения plasma значек ponoff пропадает из трея, а другие значки других приложений остаются, то же самое происходит при рестарте графического сервера.

решение: в поиске.

* 8) необходимость ручного указания маршрутов до vpn - серверов и до dns - серверов.

решение: в поиске.

* 9) стоит проверять все dns из resolf.conf и предупреждать пользователя при падении любого из них всплывающим сообщением - это при запущенном в трее ponoff; уже при первом запуске ponoff если ни один из dns-серверов из resolf.conf не отвечает, то нет смысла поднимать ppp0 - сейчас же в этом случае пакет ведет себя произвольно.

решение: в разработке.

* 10) попробовать прикрутить логику из последнего скрипта с Корбины (особенно в части динамического определения dns).

решение: при возникновении потребности в этом будет реализовано.

* 11) в конфигураторе DSL в drakconnect 2010 появился pptp туннель - подумать как его задействавать в пакете vpnpptp.

решение: особой надобности в этом нет.

* 12) подумать над тем, что кодировка у пользователей может отличаться от utf8.

решение: особой надобности в этом нет.

* 13) оптимизировать код; меньше вызывать shell если можно иначе написать.

решение: в разработке.

* 14) сделать чтобы vpnpptp и ponoff могли работать и без установки.

решение: особой надобности в этом нет.

Изменено 3 декабря 2009 пользователем romkaromka

[romkaromka 8]

Возможности версии 0.0.4.1

* 1) конфигуратор теперь автономен, он вновь пишет скрипт /etc/ppp/ip-down.d/ip-down, его признает ponoff в режиме встроенного в демон pppd реконнекта.

* 2) добавлен режим встроенного в демон pppd реконнекта (по умолчанию отключен и рекомендуется лишь для одной сетевой карты). ponoff же обрабатывает оба варианта реализации реконнекта.

* 3) реализация получения маршрутов через DHCP в порядке тестовой возможности программы (включено по умолчанию).

* 4) добавлено ведение логов pppd в порядке тестовой возможности программы (отключено по умолчанию).

* 5) заведен каталог /opt/vpnpptp/scripts - для различных скриптов, используемых программой.

* 6) заведен каталог /opt/vpnpptp/lang - для различных локализаций, используемых программой.

* 7) встроенный в демон pppd реконнект работает также как и в скрипте Корбины (показания NetApplet в этом случае хотя и верные с запаздыванием, но NetApplet перегружен и может долго не отвечать, а то и зависать; ponoff в этом случае работает лучше, чем NetApplet, не зависая и отвечая на запросы).

* 8) скрипт /etc/ppp/ip-down.d/ip-down в режиме по умолчанию (в режиме не использования встроенного в демон pppd реконнекта) ponoff прячет от демона pppd, как и раньше подкладывая ему пустушку, но возвращает его на место и все, что в этом скрипте будет записано будет непременно исполнено, поэтому от скрипта /opt/vpnpptp/ip-down отказались.

* 9) в понятие "время реконнекта" теперь вносится еще смысл "время LCP эхо-запроса" для режима встроенного в демон pppd реконнекта, в этом случае оно не может быть менее 20 сек.

* 10) проверяется "а есть ли pppd" в процессах, прежде чем убивать pppd.

* 11) оптимизирована работа ponoff в режиме неконтролирования state сетевого кабеля и в режиме встроенного в демон pppd реконнекта за счет того, что не проверяется в этом случае mii-tool вообще.

* 12) при выборе режима получения маршрутов через DHCP в конфигураторе происходит рестарт сетевых служб.

* 13) программа локализована на русский и английский языки (английский язык устанавливается сам если локализация отлична от русской).

Примечание: live-пользователь не имеет права рестарта сетевых служб, поэтому перезапускайте под root вручную командой /etc/init.d/network restart если было выбрано получение маршрутов через dhcp.

Изменено 15 декабря 2009 пользователем romkaromka

[Q1v 0]

Люди, плиз HELP ME! Сделал всё что написано выше, вроде как бы соединение есть, но захожу в Opera, набираю любой сайт - а он не открывается

 

В трее вот такой значёк зелёный и надпись такая же, что мол подключено. Может брандмауэр блокирует что? Или просто защита какая-нибудь?

[romkaromka 8]

Люди, плиз HELP ME! Сделал всё что написано выше, вроде как бы соединение есть, но захожу в Opera, набираю любой сайт - а он не открывается

 

В трее вот такой значёк зелёный и надпись такая же, что мол подключено. Может брандмауэр блокирует что? Или просто защита какая-нибудь?

1) скачайте последнюю версию http://code.google.com/p/vpnpptp/downloads/list

2) отключите файервол

[__FRY__ 0]

Скачал прогу в версии 0.0.4 Запустил. Патологически виснет при определении DHCP. При снятии соответствующей галочки запускается и интернет работает. Однако, на игровых серверах Сауербратена косяк со слишком высоким пингом. Порядка 200 - 300 мс. При этом само соединение достаточно быстрое. Предполагаю, что проблема будет проявляться на любых нелокальных игровых серверах, поскольку дело явно не в самой игре: при использовании другого провайдера (не через впн), при более низкой скорости соединения, с пингом всё в порядке. Вторая проблема в том, что не могу скачивать из DC++. Как через флайлинк, так и через linuxDC++, с локальных хабов. С хабов интернета и то и другое качает нормально. Ось - мандрива 2010. Те же самые проблемы проявляются в Ubuntu Russian Edition 9.10 и в OpenSuSe 12, и там и там соединение идёт через network manager.

Провайдер - билайн-корбина, Москва. Как работает соединение на винде, сказать не могу, по причине отсутствия оной.

[BAS2 0]

Помогите пожалуйта запустить данный пакет на Mandriva 2010 ghome...выдает сообщение "Запуск этой прогаммы возможен только под администратором и live-пользователем.Нажмите ОК для отказа от запуска"вот так

[romkaromka 8]

Скачал прогу в версии 0.0.4 Запустил. Патологически виснет при определении DHCP. При снятии соответствующей галочки запускается и интернет работает. Однако, на игровых серверах Сауербратена косяк со слишком высоким пингом. Порядка 200 - 300 мс. При этом само соединение достаточно быстрое. Предполагаю, что проблема будет проявляться на любых нелокальных игровых серверах, поскольку дело явно не в самой игре: при использовании другого провайдера (не через впн), при более низкой скорости соединения, с пингом всё в порядке. Вторая проблема в том, что не могу скачивать из DC++. Как через флайлинк, так и через linuxDC++, с локальных хабов. С хабов интернета и то и другое качает нормально. Ось - мандрива 2010. Те же самые проблемы проявляются в Ubuntu Russian Edition 9.10 и в OpenSuSe 12, и там и там соединение идёт через network manager.

Провайдер - билайн-корбина, Москва. Как работает соединение на винде, сказать не могу, по причине отсутствия оной.

Какое у Вас DE?

Чтобы одновременно работал и интернет, и локальные сети необходимо либо включить DHCP, которое у Вас не включается по непонятным пока причинам, либо прописать маршруты в соответствующее поле конфигуратора Маршрутизация

Изменено 1 марта 2010 пользователем romkaromka

[__FRY__ 0]

"Какое у Вас DE?"

KDE 4.3.2, программа соответственно в версии для KDE. Совсем забыл, что

 

Относительно маршрутизации.

"route -p add 10.0.0.0 mask 255.0.0.0 шлюз" - по ссылке. Однако, это команда для винды.

 

В вашей программе, для того же самого, я так понял нужно добавить следующие строчки:

/sbin/route add -host 10.0.0.0 netmask 255.0.0.0 gw шлюз dev eth0

/sbin/route add -net 10.0.0.0 netmask 255.0.0.0 gw шлюз dev eth0

 

Сперва я решил, что default gateway и Bcast (по команде ifconfig) - это одно и то же. Однако соответствующее редактирование строчек не помогло. Отсюда вытекает вопрос: как узнать свой шлюз? Google сказал следующее:

"1. Open a terminal window.

2. Input the following command and hit Enter:

route -n

3. The address contained in the last line (with the UG flag) is the address for your default gateway."

 

 

Вот, что я получил на это дело:

Kernel IP routing table

Destination ________ Gateway _______________Genmask _____________Flags Metric Ref Use Iface

85.21.0.98 _________10.59.216.1 _____________255.255.255.255_______UGH___0____0____0____eth0

85.21.0.91 _________10.59.216.1_____________ 255.255.255.255_______UGH___0____0____0____eth0

85.21.0.91 _________0.0.0.0_________________255.255.255.255 _______UH____0____0____ 0 ____ppp0

85.21.0.93 _________10.59.216.1_____________255.255.255.255 _______UGH___0____0____ 0____eth0

10.59.216.0_________0.0.0.0_________________255.255.248.0_________U_____5____0__

___0 ____eth0

169.254.0.0_________0.0.0.0_________________255.255.0.0__________U_____5____0___

__0 ____eth0

10.0.0.0 ___________0.0.0.0_________________255.0.0.0____________U_____0____0_____0 ____eth0

127.0.0.0 __________ 0.0.0.0_________________255.0.0.0____________U_____0____0_____0 ____lo

0.0.0.0_____________0.0.0.0_________________0.0.0.0______________U_____0_____0__

__0____ppp0

 

Последний адрес на eth0: 0.0.0.0, что как-то подозрительно, никаких UG флагов я здесь вообще не вижу.

 

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

Изменено 8 января 2010 пользователем __FRY__

[romkaromka 8]

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

исходники: http://code.google.com/p/vpnpptp/

шлюз у вас 10.59.216.1

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

Изменено 8 января 2010 пользователем romkaromka

[__FRY__ 0]

Только сейчас заметил, что шлюз сама программа умеет показывать

После того, как прописал маршруты, в дс++ на хаб корбины стало возможным заходить при включённом интернете. Однако, проблема сохранилась: при скачке файлов флайлинк показывает скорость "-1" и ничего не качает. Как и раньше, поиск файлов несмотря на это работает. Естественно, я пытаюсь скачивать только у клиентов с таким же префиксом, что и у меня.

[Scheford 0]

Только сейчас заметил, что шлюз сама программа умеет показывать

После того, как прописал маршруты, в дс++ на хаб корбины стало возможным заходить при включённом интернете. Однако, проблема сохранилась: при скачке файлов флайлинк показывает скорость "-1" и ничего не качает. Как и раньше, поиск файлов несмотря на это работает. Естественно, я пытаюсь скачивать только у клиентов с таким же префиксом, что и у меня.

iptables в плане цепочек и политик accept (т.е не настроен по умолчанию) или настраивался

[romkaromka 8]

Только сейчас заметил, что шлюз сама программа умеет показывать

После того, как прописал маршруты, в дс++ на хаб корбины стало возможным заходить при включённом интернете. Однако, проблема сохранилась: при скачке файлов флайлинк показывает скорость "-1" и ничего не качает. Как и раньше, поиск файлов несмотря на это работает. Естественно, я пытаюсь скачивать только у клиентов с таким же префиксом, что и у меня.

добавьте в таблицу маршрутизации

# хаб p2p.corbina.net:

route add -host 85.21.79.38 gw шлюз dev сетевушка

[__FRY__ 0]

добавьте в таблицу маршрутизации

# хаб p2p.corbina.net:

route add -host 85.21.79.38 gw шлюз dev сетевушка

 

С маской 255.255.255.0 ? Не помогло.

 

Может ли быть проблема в том, что при регистрации после регистрации ни ка на сайте http://p2p.corbina.ru/ я не активировал ник, поскольку, на указанный мною почтовый ящик соответствующее сообщение не пришло? И после повторного запроса на активацию тоже.

 

Внимание! Поиск и скачивание файлов доступно без регистрации на сервисе.

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

Но это не так, что было обнаружено в результате посещения друга, у которого корбина, winXP и Strong DC++.

Более того, при смене ника у него наблюдались те же самые симптомы: на хаб он заходил, но скачать ничего не мог.

 

Уточняю, что захожу на хаб и http://p2p.corbina.ru/forum с именем и паролем, указанным при регистрации на том форуме. Более того, при попытке зайти на хаб с тем же именем, но с другим паролем, или вообще без пароля, он (хаб) обрывает соединение.

Изменено 10 января 2010 пользователем __FRY__

[Scheford 0]

на сколько я знаю это 99 %,рега нужна только для чата,и на поиск и скачку ни как не влияет,так что это фантазия

[__FRY__ 0]

на сколько я знаю это 99 %,рега нужна только для чата,и на поиск и скачку ни как не влияет,так что это фантазия cool.gif

 

Однако факт остаётся фактом: как минимум в одном единичном случае на windows XP, с клиентом Strong DC++ и корбиной в москве, при смене ника (префикс оставался прежним) и удалении пароля, доступ на хаб был только формальным. По крайней мере, мы с минуту ждали скачивания списка файлов с юзеров, от которых до и после этого списки файлов скачивались за пару секунд. Возможно это только единичный случай. Но вы лично используете пароль, заходя на хаб? Если да, вы попробовали сменить логин и удалить пароль, а затем что-нибудь скачать?

[Scheford 0]

на сколько я знаю это 99 %,рега нужна только для чата,и на поиск и скачку ни как не влияет,так что это фантазия cool.gif

 

Однако факт остаётся фактом: как минимум в одном единичном случае на windows XP, с клиентом Strong DC++ и корбиной в москве, при смене ника (префикс оставался прежним) и удалении пароля, доступ на хаб был только формальным. По крайней мере, мы с минуту ждали скачивания списка файлов с юзеров, от которых до и после этого списки файлов скачивались за пару секунд. Возможно это только единичный случай. Но вы лично используете пароль, заходя на хаб? Если да, вы попробовали сменить логин и удалить пароль, а затем что-нибудь скачать?

Еще раз говорю в последний раз все работает по принципу описаному выше мною,по поводу паролей и прочие.лично счас создал новый ник, не зарегестрирированный,зашел на хаб подключился к пользователям по пирингу для проверки скачал все скачалось,вывод опять ваши фантазии,единичные случаии ,короче настраивайся не можешь значит не дорос до linux/unix еще ,без обид

[__FRY__ 0]

короче настраивайся не можешь значит не дорос до linux/unix еще ,без обид

Ну да, конечно. Это у меня, наверное, уровня не хватает. Пока до 19-го не докачаюсь, за линукс - ни-ни. А на 40-м можно будет iptables пинком по системнику настраивать.

 

А насчёт единичных случаев, так я такого повидал, что на линухе, что на винде (в своё время), что теперь меня уже практически ничем не удивишь. Не утверждаю, что конкретно я не могу скачивать с дс, потому что не активирован ник. На самом деле, просто спрашиваю, может ли такое быть. Согласен, что вряд ли проблема в этом, поскольку хаб мой логи и пароль принимает. Однако, у меня больше вариантов в голову просто не приходит. Поcкольку файерволл отключать пробовал, все маршруты уже прописал, chmod -R 777 на папку с флайлинком поставил. При том, что сам инет работает и даже вполне нормально, если не считать необъяснимо высокого пинга, я не вижу абсолютно никаких вариантов, с чем может быть косяк в dc++. Шара чуть больше 20 Гб, 15 слотов.

Можно предположить, что каким-то образом дело в системной кодировке, UT8, но это уже действительно будут фантазии.

 

Если вы так замечательно разбираетесь в настройках linux, подскажите, хотя бы приблизительно, "в какую сторону копать".

 

Возможно, по какой-то причине роуты криво прописались. Могу так предположить, поскольку, файл по ссылке ftp://ftp.corbina.net/pub/ten_megabyte скачивается со скоростью 200-300 КБ, то есть полностью соответствует моему интернет тарифу. Но скорость по локальной сети должна быть выше, а роуты для ftp я прописывал. Опять же, как и почему они могли криво прописаться, не понятно. Исходники программы у меня ещё не было времени посмотреть, но, по всей видимости, она использует системные утилиты. А в них не может быть изъяна.

 

Прилагаю снова таблицу роутинга по route -n

 

Destination_____Gateway_________Genmask_________Flags_Metric_Ref____Use_Iface

195.14.50.16____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

78.107.235.6____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______0.0.0.0_________255.255.255.255_UH____0______0________0_ppp0

195.14.50.26____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

195.14.50.93____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.90.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

85.21.79.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

10.59.216.0_____0.0.0.0_________255.255.248.0___U_____5______0________0_eth0

169.254.0.0_____0.0.0.0_________255.255.0.0_____U_____5______0________0_eth0

10.0.0.0________10.59.216.1_____255.0.0.0_______UG____0______0________0_eth0

127.0.0.0_______0.0.0.0_________255.0.0.0_______U_____0______0________0_lo

0.0.0.0_________0.0.0.0_________0.0.0.0_________U_____0______0________0_ppp0

0.0.0.0_________10.59.216.1_____0.0.0.0_________UG____5______0________0_eth0

 

Не вижу 85.21.79.38 - я его прописывал в программе.

[Scheford 0]

короче настраивайся не можешь значит не дорос до linux/unix еще ,без обид

Ну да, конечно. Это у меня, наверное, уровня не хватает. Пока до 19-го не докачаюсь, за линукс - ни-ни. А на 40-м можно будет iptables пинком по системнику настраивать.

 

А насчёт единичных случаев, так я такого повидал, что на линухе, что на винде (в своё время), что теперь меня уже практически ничем не удивишь. Не утверждаю, что конкретно я не могу скачивать с дс, потому что не активирован ник. На самом деле, просто спрашиваю, может ли такое быть. Согласен, что вряд ли проблема в этом, поскольку хаб мой логи и пароль принимает. Однако, у меня больше вариантов в голову просто не приходит. Поcкольку файерволл отключать пробовал, все маршруты уже прописал, chmod -R 777 на папку с флайлинком поставил. При том, что сам инет работает и даже вполне нормально, если не считать необъяснимо высокого пинга, я не вижу абсолютно никаких вариантов, с чем может быть косяк в dc++. Шара чуть больше 20 Гб, 15 слотов.

Можно предположить, что каким-то образом дело в системной кодировке, UT8, но это уже действительно будут фантазии.

 

Если вы так замечательно разбираетесь в настройках linux, подскажите, хотя бы приблизительно, "в какую сторону копать".

 

Возможно, по какой-то причине роуты криво прописались. Могу так предположить, поскольку, файл по ссылке ftp://ftp.corbina.net/pub/ten_megabyte скачивается со скоростью 200-300 КБ, то есть полностью соответствует моему интернет тарифу. Но скорость по локальной сети должна быть выше, а роуты для ftp я прописывал. Опять же, как и почему они могли криво прописаться, не понятно. Исходники программы у меня ещё не было времени посмотреть, но, по всей видимости, она использует системные утилиты. А в них не может быть изъяна.

 

Прилагаю снова таблицу роутинга по route -n

 

Destination_____Gateway_________Genmask_________Flags_Metric_Ref____Use_Iface

195.14.50.16____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

78.107.235.6____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______0.0.0.0_________255.255.255.255_UH____0______0________0_ppp0

195.14.50.26____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

195.14.50.93____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.90.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

85.21.79.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

10.59.216.0_____0.0.0.0_________255.255.248.0___U_____5______0________0_eth0

169.254.0.0_____0.0.0.0_________255.255.0.0_____U_____5______0________0_eth0

10.0.0.0________10.59.216.1_____255.0.0.0_______UG____0______0________0_eth0

127.0.0.0_______0.0.0.0_________255.0.0.0_______U_____0______0________0_lo

0.0.0.0_________0.0.0.0_________0.0.0.0_________U_____0______0________0_ppp0

0.0.0.0_________10.59.216.1_____0.0.0.0_________UG____5______0________0_eth0

 

Не вижу 85.21.79.38 - я его прописывал в программе.

Тогда по существу,

ftp://ftp.corbina.net/pub/ten_megabyte ,должен отрабатывать, как по локальной сети 100 mb/s, последние время я лично замечал скорость в райони 3-5 мегов,я из москвы,как на счет других городов не знаю.

По поводу высоких пингов,это всторону тех поддержки,если,что то ни так как нужно.

Далее предположим, что все политики и цепочки по умолчанию accept,и на фарик пока забили

И собственно сам dc ,как настраивал,какие настройки делал,просматривал ли FAQ по dc,там разжеванны самые распостраненые проблемы, как по поиску,подключению (-1Б ) и прочие,давай последовательно отсекай причины и в итоги все будет ок

Крути в этом направлении,пока,а там решим

Изменено 12 января 2010 пользователем Scheford

[__FRY__ 0]

Вариантов проблем тут по сути всего три (первый -- наиболее частый):

 

* Неправильно настроен межсетевой экран (файерволл, брэндмауэр, антивирус или любое другое средство сетевой защиты) у вас или у другого пользователя, и он просто блокирует сетевое соединение. в этом случае внимательно читайте данную страницу.

* Неправильно настроен DC-клиент у вас (или у того, у кого вы качаете файлы). Возможны случаи, когда вы при неверных настройках системы, сетевых экранов и т.д. вы можете что-то скачать у другого юзера, а он у вас -- нет. Рекомендуем ещё раз ознакомиться с разделом настройки DC-клиента. Если не качается вообще ни у кого, значит скорее всего проблема именно у вас, а не у других.

* Соединение по локальнй сети между двумя данными пользователями (или сегментами сети) заблокировано провайдером. В этом случае повлиять на ситуацию Вы не можете, просто считайте что данный юзер вам недоступен и воспринимайте это как данное свыше (подробнее о сегментировании сети читайте тут).

 

По первому пункту. Фаерволл я отключал. С отключённым фаерволлом работает поиск, но опять же ничего не скачивается. Отключал через графический интерфейс Центр Управления -> Безопасность. Можно было бы предположить существование какого-то ещё, неизвестного мне фаерволла, который включен по умолчанию. Но скорее всего, его нет, поскольку проблема проявлялась на всех системах, где я настраивал инет: OpenSuSe и Ubuntu Russian Remix. И там, и там через нетворк менеджер, встроенный по умолчанию. Да, Убунта РР знает о vpn из коробки. Правда, ни там, ни там я роутинги как следует не прописывал. Да и вообще, у многих стоит мандрива и в случае наличия ещё одного таинственного фаерволла, у никого ничего бы и не работало.

 

Остальные настройки DC++ на сетевые соединения никак не влияют. Так что если у вас тут всё выбрано как на картинке, значит проблема наверняка не в настройка клиента (то есть, читайте дальше).

 

Естественно, всё выбрал, как на картинке. Более того, картинка предполагает весьма ограниченное число вариантов настройки. Поэтому, я попробовал их все. Значит, не в этом дело. Опять же, если где-то закрался бы какой-то хитрый, не очевидный косяк с настройкой, это давно было бы известно и не я бы один с ним парился бы.

 

Соединение по локальнй сети между двумя данными пользователями (или сегментами сети) заблокировано провайдером.

Конечно, я пробовал качать с разных юзеров.

 

Далее предположим, что все политики и цепочки по умолчанию accept,и на фарик пока забили

С этого момента поподробнее, что за политики, что за цепочки? SELinux? Там я не копал, но у меня в нём всё стоит по умолчанию. Должно, по крайней, мере.

 

Чуть не забыл. Роутера у меня тоже нет. Зато есть dsl модем, с настроенным под него соединением. Оно проходит через ppp0, а не eth0 и теоретически повлиять на дс не может. Тем более, я принципиально не включаю оба соединения одновременно - просто выдёргиваю кабель из модема и вставляю в интернет розетку, для корбины. Или, соответственно, наоборот.

Но вот эти штуки у меня вызывают подозрение:

 

85.21.0.36______10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______0.0.0.0_________255.255.255.255_UH____0______0________0_ppp0

 

0.0.0.0_________0.0.0.0_________0.0.0.0_________U_____0______0________0_ppp0

0.0.0.0_________10.59.216.1_____0.0.0.0_________UG____5______0________0_eth0

 

Но опять же в Ubuntu RR и OpenSuSe dsl я не настраивал, а симптомы там те же.

Изменено 12 января 2010 пользователем __FRY__

[romkaromka 8]

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

взять тут ftp://ftp.linuxcenter.ru/pub/Mandriva/Edu...6/free/release/

[__FRY__ 0]

Попробовал ещё раз скачать что-нибудь у кого-нибудь, под linux DC++. У одного из пользователей мне удалось-таки скачать файлы и даже с хорошей скоростью. Однако, при скачке у остальных пользователей (естественно, я качаю только у тех, кто из моего района) опять всё тоже самое: не могу скачать даже лист файлов. По идее, кроме юзеров со своего района, я должен скачивать у юзера с ником ПОЛОЖительный. У него я тоже ничего скачать не могу. Шара чуть больше 20 Гб, 16 слотов. 0 идей, в чём дело.

 

Аналогично, удалось скачать с того же пользователя во флайлинке.

Изменено 12 января 2010 пользователем __FRY__

[GroboiD 0]

короче настраивайся не можешь значит не дорос до linux/unix еще ,без обид

Ну да, конечно. Это у меня, наверное, уровня не хватает. Пока до 19-го не докачаюсь, за линукс - ни-ни. А на 40-м можно будет iptables пинком по системнику настраивать.

 

А насчёт единичных случаев, так я такого повидал, что на линухе, что на винде (в своё время), что теперь меня уже практически ничем не удивишь. Не утверждаю, что конкретно я не могу скачивать с дс, потому что не активирован ник. На самом деле, просто спрашиваю, может ли такое быть. Согласен, что вряд ли проблема в этом, поскольку хаб мой логи и пароль принимает. Однако, у меня больше вариантов в голову просто не приходит. Поcкольку файерволл отключать пробовал, все маршруты уже прописал, chmod -R 777 на папку с флайлинком поставил. При том, что сам инет работает и даже вполне нормально, если не считать необъяснимо высокого пинга, я не вижу абсолютно никаких вариантов, с чем может быть косяк в dc++. Шара чуть больше 20 Гб, 15 слотов.

Можно предположить, что каким-то образом дело в системной кодировке, UT8, но это уже действительно будут фантазии.

 

Если вы так замечательно разбираетесь в настройках linux, подскажите, хотя бы приблизительно, "в какую сторону копать".

 

Возможно, по какой-то причине роуты криво прописались. Могу так предположить, поскольку, файл по ссылке ftp://ftp.corbina.net/pub/ten_megabyte скачивается со скоростью 200-300 КБ, то есть полностью соответствует моему интернет тарифу. Но скорость по локальной сети должна быть выше, а роуты для ftp я прописывал. Опять же, как и почему они могли криво прописаться, не понятно. Исходники программы у меня ещё не было времени посмотреть, но, по всей видимости, она использует системные утилиты. А в них не может быть изъяна.

 

Прилагаю снова таблицу роутинга по route -n

 

Destination_____Gateway_________Genmask_________Flags_Metric_Ref____Use_Iface

195.14.50.16____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

78.107.235.6____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.0.36______0.0.0.0_________255.255.255.255_UH____0______0________0_ppp0

195.14.50.26____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

195.14.50.93____10.59.216.1_____255.255.255.255_UGH___0______0________0_eth0

85.21.90.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

85.21.79.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

10.59.216.0_____0.0.0.0_________255.255.248.0___U_____5______0________0_eth0

169.254.0.0_____0.0.0.0_________255.255.0.0_____U_____5______0________0_eth0

10.0.0.0________10.59.216.1_____255.0.0.0_______UG____0______0________0_eth0

127.0.0.0_______0.0.0.0_________255.0.0.0_______U_____0______0________0_lo

0.0.0.0_________0.0.0.0_________0.0.0.0_________U_____0______0________0_ppp0

0.0.0.0_________10.59.216.1_____0.0.0.0_________UG____5______0________0_eth0

 

Не вижу 85.21.79.38 - я его прописывал в программе.

Маршрут на 85.21.79.38 есть. Это строчка

85.21.79.0______10.59.216.1_____255.255.255.0___UG____0______0________0_eth0

Для проверки локальности лучше пустить трейсик: traceroute 85.21.79.38.

 

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

[__FRY__ 0]

Для проверки локальности лучше пустить трейсик: traceroute 85.21.79.38.

 

# traceroute 85.21.79.38

bash: traceroute: command not found

 

#trace -> tab

tracepath tracepath6 traceroute6

 

#traceroute6 85.21.79.38

traceroute: unknown host 85.21.79.38

 

Включил IPv6 обратно, то же самое.

После скачки утилиты traceroute из репозитория.

 

traceroute 85.21.79.38

traceroute to 85.21.79.38 (85.21.79.38), 30 hops max, 60 byte packets

1 10.59.216.1 (10.59.216.1) 1.422 ms 2.131 ms 2.873 ms

2 10.219.149.97 (10.219.149.97) 140.800 ms 141.269 ms 141.263 ms

3 * * *

4 * * *

5 85.21.79.38 (85.21.79.38) 141.372 ms 141.367 ms 141.357 ms

 

Забавные пинги...

 

Ну и попробовать пассивный режим, а качать у активных юзеров.

 

Я таки смог скачать у одного единственного юзера, причём в активном режиме. Режим в данном случае никак не влияет.

Изменено 13 января 2010 пользователем __FRY__

[GroboiD 0]

Это в каком дистрибутиве нет traceroute? )

Судя по пингах и тому что трафик идет локально похоже на временный канал, но тут фиг знает. И это не должно влиять на соединение в хабе.

[__FRY__ 0]

Это в каком дистрибутиве нет traceroute? )

Судя по пингах и тому что трафик идет локально похоже на временный канал, но тут фиг знает. И это не должно влиять на соединение в хабе.

 

mandriva 2010 ) разве на локальный хаб траффик не должен идти локально, по идее, в этом весь смыл локального хаба? на соединение на хабе пинг, действительно не особо должно влиять, однако если уж до локального хаба такие пинги, чего уж удивляться, что у меня пинг порядка 200-300 (а то и 500) в сауербратене

[VladimirSS 3]

вот как-то так надо

Трассировка маршрута к 85.21.79.38 с максимальным числом прыжков 30

 

1 1 ms 1 ms 1 ms 10.243.32.1

2 1 ms 1 ms 1 ms 10.219.144.5

3 <1 мс <1 мс <1 мс 10.219.3.41

4 <1 мс <1 мс <1 мс ko-bb-teng12-1.msk.corbina.net [195.14.54.124]

5 <1 мс 1 ms <1 мс hq-bb-teng-4-1.msk.corbina.net [195.14.54.93]

6 <1 мс <1 мс <1 мс 85.21.79.38

 

Трассировка завершена.

[romkaromka 8]

В версии vpnpptp 0.0.5 реализовано:

1) конфигуратор сохраняет все введенные пользователем данные и последующее переконфигурирование стало удобным (логин и пароль для безопасности не хранятся в папке программы в ее config-файле), при повторной конфигурации вводить вновь ничего не надо, в полях ввода предложены ранее введенные значения, их только просто можно поправить - это позволит находить ошибки в конфигурировании и облегчит ввод из-за отсутствия необходимости повторного ввода значений,

2) новая версия файла /opt/vpnpptp/config не совместима с предыдущими его версиями, поэтому при установке программы vpnpptp 0.0.5 удалите файл /opt/vpnpptp/config,

3) теперь конфигуратор добавляет в исключения файервола интерфейсы ppp0..ppp9? и перезапускает файервол при необходимости (необходимость перезапуска также проверяется), поэтому модуль ponoff сразу же способен выйти в интернет, однако необходимо помнить, что файервол не отключен,

4) поправлены недочеты для live-пользователя, возникающие в связи с необходимостью перезапуска системных служб, на которые имеет права лишь администратор, а также при записи в директории, принадлежащие администратору; в итоге в live-режиме работать стало еще комфортнее,

5) поправлено получение маршрутов через DHCP - если уже настроено, то не перенастраивать вновь, а при отмене выбора - отменять получение маршрутов через DHCP,

6) оформлена wiki на сайте проекта пока на русском языке.

Примечание: теперь гарантируется выход в интернет - для этого и настроен файервол, однако в связи с тем, что файервол не отключен /не настроен, невозможно скачивать с хабов сети p2p, нельзя соединиться ни с одним из пользователей, не работает поиск по хабам и т.д.

При сборке пакетов обратите особое внимание на необходимость удаления файла /opt/vpnpptp/config, если он существует.

Основная страница проекта - http://code.google.com/p/vpnpptp/