Можно поинтересоваться, какие настройки были до этого? Точнее, что именно изменилось в настройках? У меня есть идея, почему не работает, но нужно подтвердить.
на будущее: привыкаем пользоваться тегами и прячем длинные портянки логов и конфигов под кат (кнопка CL).
хотелось бы еще попросить вывод команды ip ro в студию.
сейчас маршрут поумолчанию выставлен через шлюз локалки по eth0. Попробуй грохнуть дефолтный маршрут, а новым дефолтным задай тот, что через ppp0.
Кроме этого еще вопрос: пинг до какого-либо узла по IP-адресу идет? Если по IP пингуется, а по доменному имени нет, значит проблема с ДНС-серверами.
Если нет пинга до произвольных узлов, попробовать пингонуть 172.30.0.1
Еще неплохо бы посмотреть трассировку до того же 172.30.0.1 и до какого-нибудь внешнего адреса, скажем, популярный 8.8.8.8
оччень интересно. Провайдерский узел виден, а дальше затык. На этот счет у меня две мысли:
1) при поднятом ВПНе и переделанном маршруте (ниже Флеймвлауер написал, как) сделай команду traceroute 8.8.8.8
Возможно, что вместо traceroute нужно будет использовать tracert, это ты уже сам смотри, по обстоятельсвам, в данном случае разница небольшая: что поумолчанию у тебя в комплекте есть.
2) Если трассировка на 172.30.0.1 заглохнет, то тебе, скорее всего пинать техподдержку провайдера надо. Ну это, конечно, при условии, что ты нам не из параллельной винды пишешь, где все само работает.
Ну уж написал бы человеку команду по смене дефолтроута. :) sudo ip r r default via 172.30.0.1 dev ppp0
----
А топикстартеру в конфиг kabinet (/etc/ppp/peers/kabinet) следует дописать 2 строчки: defaultroute replacedefaultroute
В итоге при поднятии тоннеля у тебя дефолтный маршрут заменится по умолчанию.
Да, грешен, не подумал я как-то команду отписать, как-то был уверен, что топикстартер знает, тем более, что у него в конце поста указано, что дефолтные шлюзы он менял, хоть и неправильно, что до меня только сейчас дошло.
А что касается дефолтроута и реплейса, то обрати внимание, у него в конфиге все это прописано, однако не работает.
И таки да, ты прав. Я более чем уверен, что после выполнения указанного тобой дефолтроута все должно устаканиться само собой.
ну а трассировать то кто будет? там несколько команд трассировки, одна из них точно есть в комплекте, неуже ли так трудно в консоли набрать trac, щелкнуть табом и посмотреть, что из этого выйдет? Или мы должны телепатией определять, в каком месте у тебя затык?
Давай не так.
Показать маршруты - ip route show (кратко: ip r)
Можно еще настроечки firewall'a глянуть? iptables -nvL
Трассировку можно смотреть еще так: mtr 8.8.8.8
============
Ну и докучи посмотреть pptp.options cat /etc/ppp/options.pptp| grep -v \# | grep \.
Ну и полный файл конфига kabinet cat /etc/ppp/peers/kabinet | grep -v \# | grep \.
А то я не могу сообразить к чему относится выдержка по настройкам соединения.
по логам и ответам все ок, и маршрут нужный, и все такое. А если посмотреть на трассировку, то видно, что до провайдерского узла контакт есть, а за пределы - затык. И вот этот момент смущает. Ты нам пишешь из параллельной винды или с телефона?
Если с телефона, а параллельной операционки под рукой нет, сделай загрузочную флешку/компашку (например, живой образ инсталлятора кубунты), и грузанись туда и попробуй там начистую поднять ВПН. Как вариант - снести начисто текущие настройки соединения и завести заново. Но я бы все же поэкспериментировал сначала с "живого образа".
пишу с ноута, подцепленного к чужому вайфаю (пиратствую, да)
на самом деле, был уже даже вариант переустановки системы опробован, но реинкарнация не помогла(
172.30.0.1 dev ppp0 proto kernel scope link src 31.167.171.49
172.30.0.1 dev ppp1 proto kernel scope link src 31.167.171.49
А это что?
Еще смущает опция:
noproxyarp
Если попробовать без нее?
закомментировала noproxyarp, ничего не изменилось(
мне вот ещё интересно, почему при pon kabinet debug nodetach каждый раз создаётся новый ppp (ppp1, ppp2, ppp3...)
Разве replacedefaultroute не должен его на ppp0 заворачивать?
в общем, ситуация получила вот какое развитие: на недобуке у меня стоит параллельно винда семёрка, я решила по инструкциям поднять VPN на ней.
Поскольку техподдержка Кабинет при слове "линукс" начинает вопить "чур меня-чур" и бросать трубки, решила дать им типовую задачку.
И что вы думаете? Всё настроилось, и локалка и VPN, только доступа никуда нет.
Два раза по полчаса пытала мальчиков из техподдержки. Что-то они там у себя тык-мык-тык-мык делали, потом пробовали сменить мне серый айпишник - результата ноль.
Хотели мне прогнать "это у вас в операционке проблема" - тут я им карты открыла, что уже неделю билась на одном компе, а сейчас и комп другой, и операционка, и всё равно не канает.
В итоге мальчики меня оставили висеть на линии ещё минут 5, потом сказали, что "передали проблему в соответствующую службу" и там это "будут решать".
Посмотрим, конечно. Скорее всего просто поменяю провайдера на более вменяемого.
ага, с них станется((
зато появилось некоторое облегчение, что это не мои кривые руки виноваты;)
Вам СПАСИБО всем, что не пожалели времени и стали вникать!
Если всё-таки решится - отпишусь.
Можно поинтересоваться, какие настройки были до этого? Точнее, что именно изменилось в настройках? У меня есть идея, почему не работает, но нужно подтвердить.
До этого было всё то же самое, но в /etc/ppp/peers kabinet (и в chap-secrets, соответственно) был старый "белый" ip-шник прописан.
на будущее: привыкаем пользоваться тегами и прячем длинные портянки логов и конфигов под кат (кнопка CL).
хотелось бы еще попросить вывод команды ip ro в студию.
сейчас маршрут поумолчанию выставлен через шлюз локалки по eth0. Попробуй грохнуть дефолтный маршрут, а новым дефолтным задай тот, что через ppp0.
Кроме этого еще вопрос: пинг до какого-либо узла по IP-адресу идет? Если по IP пингуется, а по доменному имени нет, значит проблема с ДНС-серверами.
Если нет пинга до произвольных узлов, попробовать пингонуть 172.30.0.1
Еще неплохо бы посмотреть трассировку до того же 172.30.0.1 и до какого-нибудь внешнего адреса, скажем, популярный 8.8.8.8
оччень интересно. Провайдерский узел виден, а дальше затык. На этот счет у меня две мысли:
1) при поднятом ВПНе и переделанном маршруте (ниже Флеймвлауер написал, как) сделай команду
traceroute 8.8.8.8Возможно, что вместо traceroute нужно будет использовать tracert, это ты уже сам смотри, по обстоятельсвам, в данном случае разница небольшая: что поумолчанию у тебя в комплекте есть.
2) Если трассировка на 172.30.0.1 заглохнет, то тебе, скорее всего пинать техподдержку провайдера надо. Ну это, конечно, при условии, что ты нам не из параллельной винды пишешь, где все само работает.
Ждем результатов.
на traceroute требует установить доп пакет, чего я не могу, а на tracert -- предлагает только tracer (из какого-то левого пакета)
tracepath точно есть в базовой комплектации.
Ну уж написал бы человеку команду по смене дефолтроута. :)
sudo ip r r default via 172.30.0.1 dev ppp0----
А топикстартеру в конфиг kabinet (/etc/ppp/peers/kabinet) следует дописать 2 строчки:
defaultroutereplacedefaultroute
В итоге при поднятии тоннеля у тебя дефолтный маршрут заменится по умолчанию.
Да, грешен, не подумал я как-то команду отписать, как-то был уверен, что топикстартер знает, тем более, что у него в конце поста указано, что дефолтные шлюзы он менял, хоть и неправильно, что до меня только сейчас дошло.
А что касается дефолтроута и реплейса, то обрати внимание, у него в конфиге все это прописано, однако не работает.
И таки да, ты прав. Я более чем уверен, что после выполнения указанного тобой дефолтроута все должно устаканиться само собой.
ну а трассировать то кто будет? там несколько команд трассировки, одна из них точно есть в комплекте, неуже ли так трудно в консоли набрать trac, щелкнуть табом и посмотреть, что из этого выйдет? Или мы должны телепатией определять, в каком месте у тебя затык?
Давай не так.
Показать маршруты - ip route show (кратко: ip r)
Можно еще настроечки firewall'a глянуть?
iptables -nvL
Трассировку можно смотреть еще так:
mtr 8.8.8.8
============
Ну и докучи посмотреть pptp.options
cat /etc/ppp/options.pptp| grep -v \# | grep \.Ну и полный файл конфига kabinet
cat /etc/ppp/peers/kabinet | grep -v \# | grep \.А то я не могу сообразить к чему относится выдержка по настройкам соединения.
по логам и ответам все ок, и маршрут нужный, и все такое. А если посмотреть на трассировку, то видно, что до провайдерского узла контакт есть, а за пределы - затык. И вот этот момент смущает. Ты нам пишешь из параллельной винды или с телефона?
Если с телефона, а параллельной операционки под рукой нет, сделай загрузочную флешку/компашку (например, живой образ инсталлятора кубунты), и грузанись туда и попробуй там начистую поднять ВПН. Как вариант - снести начисто текущие настройки соединения и завести заново. Но я бы все же поэкспериментировал сначала с "живого образа".
пишу с ноута, подцепленного к чужому вайфаю (пиратствую, да)
на самом деле, был уже даже вариант переустановки системы опробован, но реинкарнация не помогла(
А это что?
Еще смущает опция:
noproxyarp
Если попробовать без нее?
закомментировала noproxyarp, ничего не изменилось(
мне вот ещё интересно, почему при pon kabinet debug nodetach каждый раз создаётся новый ppp (ppp1, ppp2, ppp3...)
Разве replacedefaultroute не должен его на ppp0 заворачивать?
replacedefaultroute не запрещает создавать новые интерфейсы.
в общем, ситуация получила вот какое развитие: на недобуке у меня стоит параллельно винда семёрка, я решила по инструкциям поднять VPN на ней.
Поскольку техподдержка Кабинет при слове "линукс" начинает вопить "чур меня-чур" и бросать трубки, решила дать им типовую задачку.
И что вы думаете? Всё настроилось, и локалка и VPN, только доступа никуда нет.
Два раза по полчаса пытала мальчиков из техподдержки. Что-то они там у себя тык-мык-тык-мык делали, потом пробовали сменить мне серый айпишник - результата ноль.
Хотели мне прогнать "это у вас в операционке проблема" - тут я им карты открыла, что уже неделю билась на одном компе, а сейчас и комп другой, и операционка, и всё равно не канает.
В итоге мальчики меня оставили висеть на линии ещё минут 5, потом сказали, что "передали проблему в соответствующую службу" и там это "будут решать".
Посмотрим, конечно. Скорее всего просто поменяю провайдера на более вменяемого.
воооот! а я говорил, что это провайдер мозг компостирует! =)
ага, с них станется((
зато появилось некоторое облегчение, что это не мои кривые руки виноваты;)
Вам СПАСИБО всем, что не пожалели времени и стали вникать!
Если всё-таки решится - отпишусь.
обычно надеешься на лучшее, а получается как всегда )))
Меня настолько тема зацепила, что я даже загуглил .
Всё же стоит попробовать ip route add default via 31.167.171.49 dev ppp0 после поднятия интерфейса.
Ещё рекомендовали прописать маршруты для dns'ов.
ip route add 87.224.197.1 via 31.167.171.49
ip route add 87.224.213.1 via 31.167.171.49
а я-то сколько гуглила! ;))
такие приёмчики тоже не прошли, поскольку, похоже, дело не в настройках (см.выше)
Отправить комментарий