LINUX.ORG.RU
Форум — General  

Чуть-чуть не хватает ...


0

1

Уже писал на форум на эту тему. Немного подразобрался, но все равно ничего не работает.

Необходимо подключиться к интернету через vpn. Подключение осуществляется через pptp-client.

Адрес vpn-сервера - 10.20.0.1

Операционная система FreeBSD 7.0

Содержание файла /etc/ppp/ppp.conf 

vpn:
 set authname name
 set authkey  password
 set timeout  0
 set ifaddr 0 0
 set default HISADDR
 alias enable yes
Команда
netstat -rnW
выдает следующие данные 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
10.20.0.0/21       link#1             UC          0        0   1500      rl0
10.20.0.1          00:18:fe:86:ca:64  UHLW        2       76   1500      rl0   1199
83.229.168.47/32   10.20.0.1          UGS         0        0   1500      rl0
127.0.0.1          127.0.0.1          UH          0       26  16384      lo0

Internet6:
Destination                       Gateway                       Flags    Refs      Use    Mtu    Netif Expire
::1                               ::1                           UHL         1        0  16384      lo0
fe80::%lo0/64                     fe80::1%lo0                   U           0        0  16384      lo0
fe80::1%lo0                       link#3                        UHL         1        0  16384      lo0
ff01:3::/32                       fe80::1%lo0                   UC          0        0  16384      lo0
ff02::%lo0/32                     fe80::1%lo0                   UC          0        0  16384      lo0
После запуска команды
pptp 10.20.0.1 vpn
появляется новый интерфейс 
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1498
        inet 10.9.2.45 --> 10.9.0.254 netmask 0xffffffff 
        Opened by PID 887
После этого вывод команды
netstat -rnW
выглядит следующим образом 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
10.9.0.254         10.9.2.45          UGH         0        0   1498     tun0
10.20.0.0/21       link#1             UC          0        0   1500      rl0
10.20.0.1          00:18:fe:86:ca:64  UHLW        2      110   1500      rl0   1198
83.229.168.47/32   10.20.0.1          UGS         0        0   1500      rl0
127.0.0.1          127.0.0.1          UH          0       26  16384      lo0

Internet6:
Destination                       Gateway                       Flags    Refs      Use    Mtu    Netif Expire
::1                               ::1                           UHL         1        0  16384      lo0
fe80::%lo0/64                     fe80::1%lo0                   U           0        0  16384      lo0
fe80::1%lo0                       link#3                        UHL         1        0  16384      lo0
ff01:3::/32                       fe80::1%lo0                   UC          0        0  16384      lo0
ff01:4::/32                       link#4                        UGC         0        0   1498     tun0
ff02::%lo0/32                     fe80::1%lo0                   UC          0        0  16384      lo0
ff02::%tun0/32                    fe80::20d:88ff:fe45:a0dc%tun0 UGC         0        0   1500     tun0
Однако ничего не работает. Чувствую, что еще немного и все заработает. Может роуты какие надо прописать?

← Debian Lenny и свежий apache
Перенос виртуалки с одного vbox на другой vbox →
Ответ на: комментарий от Ximen

Маршурт по умолчанию

В том-то и дело, что перед подключением его нет.

Если написать 

route add default 10.20.0.1
то не будет соединяться вообще.

ivan_russian
() автор топика
Ответ на: комментарий от Ximen

Маршруты по умолчанию

Значит, если перед подлючением написать команду, 

route add default 10.20.0.1
то будет соответсвтующий маршрут по умолчанию. Но тогда не всегда подлючается.

Далее набираем команду 

pptp 10.20.0.1 vpn
Получаем такой вывод 
/bin/ip: not found
/bin/ip: not found
Loading /lib/libalias_cuseeme.so
Loading /lib/libalias_ftp.so
Loading /lib/libalias_irc.so
Loading /lib/libalias_nbt.so
Loading /lib/libalias_pptp.so
Loading /lib/libalias_skinny.so
Loading /lib/libalias_smedia.so
Программа остается висеть. А дальше, если перед подключением маршрутов по умолчанию не было, то их и нет после подключения. А если были, то после подключения маршуртом по умолчанию остается либо 
10.20.0.1
либо становится 
10.9.0.254

ivan_russian
() автор топика
Ответ на: Маршруты по умолчанию от ivan_russian

Попробуй после подключения сделать что-то вроде route add default dev tun0. Хотя, 10.9.0.254 тоже должен работать...

Ximen ★★★★
()

нет дефолтового шлюза.
должно помочь s/set default HISADDR/add default HISADDR/
либо если шлюз уже есть, s/set default HISADDR/add! default HISADDR/

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

Дефолтный шлюз

Не совсем понятно, что означает

s/set default HISADDR/add default HISADDR/

Ведь в файле /etc/ppp/ppp.conf есть строка 

set default HISADDR

Кроме того, замечена интересная закономерность. До подключения 10.9.0.254 - пингуется, но не пингуется 10.9.2.45. После подключения 10.9.0.254 - не пингуется. (Почему?) А 10.9.2.45 - пингуется.

10.20.0.1 - пингуется всегда

ivan_russian
() автор топика
Ответ на: Дефолтный шлюз от ivan_russian

1. замени «set default HISADDR» на «add default HISADDR»
2. начинает пинговаться потому чо появляется новый интерфейс/ему назначается адрес. А сервер пингуется всегда, потому как он доступен всегда, ваш КО.
3. И маны хотя бы чтоли почитай

FollowTheRabbit ★
()
Ответ на: Дефолтный шлюз от ivan_russian

и у тя в сетке где то доступен 10.9.0.254, если он пингуется еще ДО подключения. И фаервол отключи пока. Скорее всего у тя запрещена сетевая активность tun0, раз ПОСЛЕ подключения, с корректно прописанным маршрутом перестает пинговаться 10.9.0.254

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

Фаервол

Я прошу простить меня за дилетантизм. Просто 3 дня бьюсь, ничего не получается. Я никаких фаерволов не ставил. Значит, очевидно, стоит фаервол по умолчанию (ipfw а может еще что). Можешь кинуть команду отключения фаервола, а то я если начну искать, то это еще на неделю. Мне просто inet нужен, а фаервол пусть будет отключен.

Заранее благодарен.

ivan_russian
() автор топика
Ответ на: Фаервол от ivan_russian

ipfw по умолчанию отключен. но если что, найти как отключить - минута в гугле, в Курске гугл еще работает ведь? После замены set/add дефолтовый шлюз не прописался чтоли? Все уже должно было заработать, если конечно 10.20.0.1 не где нить за маршрутизатором, если это так пропиши к нему маршрут руками. И прочитай наконец маны, таким способом как спрашивать на форумах, решать проблемы глупо (на лоре это вообще моветон).

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

На самом деле читал маны...что-то не помогает. Пробовал ставить mpd, перекомпилировал ядро с поддержкой mpd.

А по поводу файла /etc/ppp/ppp.conf. Там я этот файл много раз редактировал. Просто прислал одну из версий. Все я сделал, так как ты говоришь, ничего не получилось.

В Linux все заработало сразу, а здесь...

А по поводу 10.0.0.254 ... В windows просто пишет после подключения

ip-адрес сервера 10.9.0.254 ip-адрес клиента 10.9.2.45

И адрес 10.9.0.254 в windows пингуется как до соединения, так и после. Чего в FreeBSD не наблюдается. Возможно это просто случайный адрес в сети а возможно и нет.

Кроме того ребята говорил, что нужно разрешить цикл в роутинге, иначе ничего не заработает. 

route delete -host 10.20.0.1
Пробовал подобным образом - не получается все равно.

И набирал, 

route delete default
route add default 10.9.0.254
и так далее и в таком духе

В общем ничего не выходит.

А за помощью в любом случае спасибо.

ivan_russian
() автор топика
Ответ на: комментарий от ivan_russian

1. 10.20.0.1 находится в вашей подсети?
2. add! default HISADDR в конфиг вписали? что есть в таблице маршрутизации после подключения (сюда скопировать)? Если там нет дефолтового маршрутизатора (в чем я очень сомневаюсь), что в логах?

route delete -host 10.20.0.1

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

FollowTheRabbit ★
()
Ответ на: комментарий от ivan_russian

> И набирал,

route delete default

route add default 10.9.0.254

и так далее и в таком духе

В общем ничего не выходит.


При поднятом подключении? Если все правильно сделали у вас пинг на какой нить гугл должен идти через tun0. Скорее всего так оно и есть. В таком случае, если сервер не отвечает, ковыряйте его. На сервере 10.9.2.54 жестко не замаршрутизирован куданить не туда?

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

Содержание файла /etc/ppp/ppp.conf 

vpn:
 set authname name
 set authkey  password
 set timeout  0
 set ifaddr 0 0
 add default HISADDR
 alias enable yes
набираю команду 
pptp 10.20.0.1 vpn
получаю вывод 
/bin/ip: not found
/bin/ip: not found
Loading /lib/libalias_cuseeme.so
Loading /lib/libalias_ftp.so
Loading /lib/libalias_irc.so
Loading /lib/libalias_nbt.so
Loading /lib/libalias_pptp.so
Loading /lib/libalias_skinny.so
Loading /lib/libalias_smedia.so
Появляется новый интерфейс 
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1498
        inet 10.9.2.45 --> 10.9.0.254 netmask 0xffffffff 
        Opened by PID 887
Вывод команды 
netstat -rnW
имеет следующий вид 
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
default            10.9.0.254         UGS         1        0   1500     tun0
10.9.0.254         10.9.2.45          UGH         1        0   1498     tun0
10.20.0.0/21       link#1             UC          0        0   1500      rl0
10.20.0.1          00:18:fe:86:ca:64  UHLW        2      100   1500      rl0   1199
83.229.168.47/32   10.20.0.1          UGS         0        0   1500      rl0
127.0.0.1          127.0.0.1          UH          0       26  16384      lo0

Internet6:
Destination                       Gateway                       Flags    Refs      Use    Mtu    Netif Expire
::1                               ::1                           UHL         1        0  16384      lo0
fe80::%lo0/64                     fe80::1%lo0                   U           0        0  16384      lo0
fe80::1%lo0                       link#3                        UHL         1        0  16384      lo0
ff01:3::/32                       fe80::1%lo0                   UC          0        0  16384      lo0
ff01:4::/32                       link#4                        UGC         0        0   1498     tun0
ff02::%lo0/32                     fe80::1%lo0                   UC          0        0  16384      lo0
ff02::%tun0/32                    fe80::20d:88ff:fe45:a0dc%tun0 UGC         0        0   1500     tun0

PS. Еще раз прошу прощения. Заработает или не заработает, в любом случае спасибо

ivan_russian
() автор топика
Ответ на: комментарий от ivan_russian

проверьте tcdump'ом что у вас пинг на какой нить 8.8.8.8 уходит на 10.9.0.254 через tun0 (что бы отсечь фаервол). Если уходит, но не возвращается, проблема на на вашем хосте. Значит либо на сервере 10.9.2.54 жестко не замаршрутизирован куданить не туда, либо на следующих хопах не прописан маршрут к 10.9.2.45.
Что бы исключить хопы попробуйте пинговать другой интерфейс/алиас сервера. Если пингуется - дело в хопах. Если нет - смотрите таблицу маршрутизации при поднятом подключении на сервере.

FollowTheRabbit ★
()

у pptp есть опция defaultroute. вот с ней надо и пускать.

Komintern ★★★★★
()
Ответ на: комментарий от FollowTheRabbit

tcpdump

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

ping 8.8.8.8
После чего была запущена команда 
tcpdump -i tun0

Вывод команды имеет следующий вид: 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
23:39:22.030875 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 0, length 64
23:39:23.031026 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 1, length 64
23:39:24.032028 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 2, length 64
23:39:25.033035 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 3, length 64
23:39:26.034036 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 4, length 64
23:39:27.035091 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 5, length 64
23:39:28.036050 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 6, length 64
23:39:29.037047 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 7, length 64
23:39:30.038057 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 8, length 64
23:39:31.039054 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 9, length 64
23:39:32.040064 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 10, length 64
23:39:33.041064 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 11, length 64
23:39:34.042064 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 12, length 64
23:39:35.043075 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 13, length 64
23:39:36.044075 IP 10.9.2.45 > google-public-dns-a.google.com: ICMP echo request, id 56067, seq 14, length 64

ivan_russian
() автор топика
Ответ на: комментарий от ivan_russian

=D нет. Я не фанат фри, но в данном случае нет, не может.
О чем вообще речь? Фря подняла тоннель, посылает туда пакеты, все что должно было быть сделано, сделано. Ковыряйте сервер, маршруты на нем и другие хопах, как я писал выше.

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

Еще раз прошу прощения за дилетантизм. Но не могли бы вы чуть-чуть поконкретнее охарактеризовать фронт работ.

Ковыряйте сервер, маршруты на нем и другие хопах

Как я погу поковырять сервер (судя по всему это 10.9.0.254) со своей машины?

Как я могу поковырять маршруты на нем со своей машины?

Что такое хоп? (Понимаю, вопрос звучит глупо, и человеку, задавашему такой вопрос, хочется оторвать руки, но простите)

PS Еще раз прошу прощение за свою назойливость. И спасибо большое за помощь

ivan_russian
() автор топика
Ответ на: комментарий от ivan_russian

А что, сервер не под вашим контролем? Значит обратитесь к человеку, кто его админит.
Нужно выяснить, почему сервер не шлет обратно на ваш хост (10.9.2.45) ответ на пинг. И именно посмотреть его таблицу маршрутизации на предмет того, куда пойдут пакеты предназначенные адресу 10.9.2.45.
Что можете сделать прямо сейчас. Пропинговать сам сервер. Если он вам не ответит, значит таблица маршрутизации на нем неправильная и ее нужно исправлять.

FollowTheRabbit ★
()
Ответ на: комментарий от FollowTheRabbit

Адрес 10.20.0.1 пингуется всегда (Мне дали только его и сказали, что это и есть сервер)

Адрес 10.9.0.254 не пингуется. (Если немножко позаморачиваться, то он может пинговаться перед pptp-соединением, но после соединения не пингуется никак)

Адрес kstu.kursk.ru пингуется всегда, но является ли он сервером, я не знаю, возможно он выполняет другие функции.

Просто удивительно, как при клиентской ОС Window и Linux сервер все обрабатывает нормально, а при FreeBSD не хочет работать.

PS. Все, спасибо вам большое, извините за беспокойство, просто без вашей помощи я бы вообще не понял, в чем дело.

ivan_russian
() автор топика
Ответ на: комментарий от ivan_russian

Ничего удивительного. Видимо при клиентской ОС Window и Linux, вашему хосту был назначен иной адрес, а не 10.9.2.45. А с фрей вам назначили 10.9.2.45, но к несчастью на сервере этот адрес или диапазон, куда он входит, уже замаршрутизирован не туда. Почему сервер выдает клиентам такие адреса, с которыми он не работает - это вопрос тому кто настраивал сервер. Адрес 10.9.0.254 скорее всего является интерфейсом сервера(или прописан алиасом), поэтому может пинговаться когда подключения нет.

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

у меня лимит помощи кому-л. исчерпался на 2 года вперед =)

FollowTheRabbit ★
()
Ответ на: комментарий от ivan_russian

> набираю команду

pptp 10.20.0.1 vpn

получаю вывод

/bin/ip: not found

/bin/ip: not found

Loading /lib/libalias_cuseeme.so

...

Вот это вот

/bin/ip: not found

- это так и задумано, или что-то не ладно, всё ж, в консерватории? Сделайте линк /sbin/ip в /bin/ip, иди где оно там у вас...

nbw ★★★
()
Ответ на: комментарий от nbw

> это так и задумано, или что-то не ладно, всё ж, в консерватории?
Это так и задумано, исправляется потом костыликами в скриптах.

Сделайте линк /sbin/ip в /bin/ip, иди где оно там у вас...

Для фряхи это вредный совет. Потому что там ip нет.

Lumi ★★★★★
()
Ответ на: комментарий от Lumi

> Для фряхи это вредный совет. Потому что там ip нет.

Ясно, прошу пардону. С FreeBSD волею судеб ушел этак во времена 6.2, посему не помню таких подробностей.

nbw ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Debian Lenny и свежий apache
General
Перенос виртуалки с одного vbox на другой vbox →