[Comm] пробл с VPN

[Comm] пробл с VPN

[khudyakov]

Здравствуйте всем!
Столкнулся со следующей проблемой. Не могу соединиться с VPN сервером
с линуксовой машины. Сервер работает более года безупречно, все
виндовые машины авторизуются и работают также. На сервере RedHat, ядро
2.4.22. клиентская машина на AltLinux Master2.2.
При попытке коннекта взводятся ppp интерфейсы на сервере и клиенте,
проходит авторизация успешно  и потом все....
Включил опцию debug  на обеих машинах и получил вот что ( подробнее см
.файл). на сервере пишет:
local  IP address 192.168.1.1rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
sent [CCP ConfRej id=0x1 <mppe 1 0 0 40>]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
sent [CCP ConfReq id=0x2]
rcvd [IPCP ConfReq id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
Cannot determine ethernet address for proxy ARP
local  IP address 192.168.1.1
remote IP address 192.168.22.33
Script /etc/ppp/ip-up started (pid 19339)
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
rcvd [CCP ConfAck id=0x2]
Received bad configure-ack:
Script /etc/ppp/ip-up finished (pid 19339), status = 0x0
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
CCP: timeout sending Config-Requests
Terminating on signal 2.
Modem hangup
Script /etc/ppp/ip-down started (pid 19504)
Connection terminated.
Connect time 2.1 minutes.
Sent 106 bytes, received 76 bytes.
Waiting for 1 child processes...
  script /etc/ppp/ip-down, pid 19504
Script /etc/ppp/ip-down finished (pid 19504), status = 0x0

      А НА КЛИЕНТЕ 192.168.1.33
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3457df24> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3457df24> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x3457df24]
rcvd [CHAP Challenge id=0x1 <4d4ff8a58b0443c618c9dcbb404c2e9b>, name = "*"]
sent [CHAP Response id=0x1 <f7c60cf40efcdaa1008975c810bd916900000000000000009c71
d709c53cf2941e9601132411b1d284ad65bd640d6e1800>, name = "Goshik"]
rcvd [LCP EchoRep id=0x0 magic=0x187d49c8]
rcvd [CHAP Success id=0x1 "S=A9C96D2B40F1217D4CE96938D3D7C409B671FEA2"]
Remote message: S=A9C96D2B40F1217D4CE96938D3D7C409B671FEA2
sent [IPCP ConfReq id=0x1 <addr 192.168.1.33> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <mppe 1 0 0 60]
rcvd [IPCP ConfReq id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 60]
sent [CCP ConfNak id=0x1 <mppe 1 0 0 40]
rcvd [IPCP ConfNak id=0x1 <addr 192.168.22.33>]
sent [IPCP ConfReq id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
rcvd [CCP ConfRej id=0x1 <mppe 1 0 0 40]
sent [CCP ConfReq id=0x2]
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
rcvd [IPCP ConfAck id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
local  IP address 192.168.22.33
remote IP address 192.168.1.1
Script /etc/ppp/ip-up started (pid 3447)
Script /etc/ppp/ip-up finished (pid 3447), status = 0x0
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [LCP EchoReq id=0x1 magic=0x3457df24]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
sent [CCP ConfReq id=0x2]
CCP: timeout sending Config-Requests
sent [LCP EchoReq id=0x2 magic=0x3457df24]
sent [LCP EchoReq id=0x3 magic=0x3457df24]
sent [LCP EchoReq id=0x4 magic=0x3457df24]
sent [LCP EchoReq id=0x5 magic=0x3457df24]
Script pptp 192.168.1.1 --nolaunchpppd finished (pid 3433), status = 0x0
Modem hangup
Script /etc/ppp/ip-down started (pid 3542)
Connection terminated.
Connect time 2.1 minutes.
Sent 2754297300 bytes, received 66 bytes.
Waiting for 1 child processes...
  script /etc/ppp/ip-down, pid 3542
Script /etc/ppp/ip-down finished (pid 3542), status = 0x0

Обидноза линукс в том смысле что в винде ничо не надо донастраивать, а
здесь темный лес...
Конфигурация файлов options сервера и клиента прилагается (в файле).
Огромная просьба помочь - в сети есть еще несколько машин на Alt
С уважением Худяков Игорь.
      


-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: [Comm] пробл с VPN

[max]

khudyakov пишет:

У меня было что-то подобное.
Файервол должен пропускать протокол gre.
Эсли проблема в этом можно легко проверить:
tcpdump -i iface или iptraf
и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
идут.

iptables -p 47 -j ACCEPT решит проблему


-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re: [Comm] пробл с VPN

[max]

max пишет:
> khudyakov пишет:
> 
> У меня было что-то подобное.
> Файервол должен пропускать протокол gre.
> Эсли проблема в этом можно легко проверить:
> tcpdump -i iface или iptraf
> и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
> идут.
> 
> iptables -p 47 -j ACCEPT решит проблему
> 
Загнался немного iptables -A FORWARD -p 47 -j ACCEPT
или iptables -A OUTPUT -p 47 -j ACCEPT и iptables -A INPUT -p 47 -j ACCEPT
-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re: [Comm] пробл с VPN

[Pavel Sabirjanov]

Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
А из под одного ната у Вас работают 3-4-5 машин?
Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
patch-o-matic (www.netfilter.org)

khudyakov пишет:

>Здравствуйте всем!
>Столкнулся со следующей проблемой. Не могу соединиться с VPN сервером
>с линуксовой машины. Сервер работает более года безупречно, все
>виндовые машины авторизуются и работают также. На сервере RedHat, ядро
>2.4.22. клиентская машина на AltLinux Master2.2.
>При попытке коннекта взводятся ppp интерфейсы на сервере и клиенте,
>проходит авторизация успешно  и потом все....
>Включил опцию debug  на обеих машинах и получил вот что ( подробнее см
>.файл). на сервере пишет:
>
>
>Обидноза линукс в том смысле что в винде ничо не надо донастраивать, а
>здесь темный лес...
>Конфигурация файлов options сервера и клиента прилагается (в файле).
>Огромная просьба помочь - в сети есть еще несколько машин на Alt
>С уважением Худяков Игорь.
>      
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Community mailing list
>Community@altlinux.ru
>https://lists.altlinux.ru/mailman/listinfo/community
>


-- 
С уважением,
Сабирьянов Павел
pavel@ukr-inter.net

Re: [Comm] пробл с VPN

[max]

khudyakov пишет:

> Здравствуйте, max.
> 
> Вы писали 14 октября 2004 г., 18:20:40:
> 
> m> max пишет:
> 
>>>khudyakov пишет:
>>>
>>>У меня было что-то подобное.
>>>Файервол должен пропускать протокол gre.
>>>Эсли проблема в этом можно легко проверить:
>>>tcpdump -i iface или iptraf
>>>и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
>>>идут.
>>>
>>>iptables -p 47 -j ACCEPT решит проблему
>>>
> 
> m> Загнался немного iptables -A FORWARD -p 47 -j ACCEPT
> m> или iptables -A OUTPUT -p 47 -j ACCEPT и iptables -A INPUT -p 47 -j ACCEPT
> 
> Так при коннекте более ста машин на виндах проблем с файрволом то на
>  сервере нет..

Я про локальный файрвол на клиенте.
И tcpdump смотри на клиенте. У меня была в этом проблема, если не то, 
другим помочь не смогу.
-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re: [Comm] пробл с VPN

[max]

Pavel Sabirjanov пишет:
> Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
> А из под одного ната у Вас работают 3-4-5 машин?
> Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
> patch-o-matic (www.netfilter.org)
> 
У меня на клиенте вообще нет /proc/net/ip_conntrack, а что там должно быть?
И для чего нужен патч pptp-conntrack-nat?

Re: [Comm] пробл с VPN

[Pavel Sabirjanov]

khudyakov пишет:

>    Дело в том что в сети 140 клиентских машин, из них только 6 на
>    линуксе,за год не было проблем с коннектом на 1723 порт
>
>  
>
Значит проблема в клиентской стороне, Вам уже написали что посмотреть.

-- 
С уважением,
Сабирьянов Павел
pavel@ukr-inter.net

Re: [Comm] пробл с VPN

[max]

>        в ip_conntrack нечто подобное что и в логах - пакеты  SYN и SYN
>        ACK а  соединение в состояние установленное не переходит.
>        на  стороне клиента за 2 минуты с интерфейса ррр уходит пакетов
>        до 900 мегабайт в ццелом, а принято 93кб....(может дело в
>        маршрутизации?)
> 
  Если связь между машинами есть, значит маршрутизация не при чём.
Хотя если впн-сервер за шлюзом и используется defaultroute, шлюз 
сброситься и клиент будет думать что впн-сервер за ррр-интерфейсом,
и связь разорвётся. Такое тоже видел.
Пропиши на клиенте статический маршрут до впн-сервера.
route add [ip впн-сервер] gw [шлюз] dev [iface шлюза]
-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re: [Comm] пробл с VPN

[Pavel Sabirjanov]

max пишет:

> Pavel Sabirjanov пишет:
>
>> Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
>> А из под одного ната у Вас работают 3-4-5 машин?
>> Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
>> patch-o-matic (www.netfilter.org)
>>
> У меня на клиенте вообще нет /proc/net/ip_conntrack, а что там должно 
> быть?
> И для чего нужен патч pptp-conntrack-nat?
>
Если у ната, из под которого соединяется более одного клиента, нет 
хелпер модуля, то на VPN-сервере нужно пропатчить ядро, iptables, и 
собрать модули ip_conntrack_pptp, ip_conntrack_proto_gre. (я их уже 
собрал, осталось проверить)

-- 
С уважением,
Сабирьянов Павел
pavel@ukr-inter.net

Re: [Comm] пробл с VPN

[max]

khudyakov пишет:
> Здравствуйте, max.
> 
> Вы писали 14 октября 2004 г., 19:09:07:
> 
> 
>>>       в ip_conntrack нечто подобное что и в логах - пакеты  SYN и SYN
>>>       ACK а  соединение в состояние установленное не переходит.
>>>       на  стороне клиента за 2 минуты с интерфейса ррр уходит пакетов
>>>       до 900 мегабайт в ццелом, а принято 93кб....(может дело в
>>>       маршрутизации?)
>>>
> 
> m>   Если связь между машинами есть, значит маршрутизация не при чём.
> m> Хотя если впн-сервер за шлюзом и используется defaultroute, шлюз 
> m> сброситься и клиент будет думать что впн-сервер за ррр-интерфейсом,
> m> и связь разорвётся. Такое тоже видел.
> m> Пропиши на клиенте статический маршрут до впн-сервера.
> m> route add [ip впн-сервер] gw [шлюз] dev [iface шлюза]
> 
>        VPN сервер физически находится на шлюзе и в options.pptp на
>        клиенте добавлен  дефолтный  маршрут
> 
>           файл options на vpn сервере 192.168.1.1
> ## SAMPLE ONLY
> ## CHANGE TO SUIT YOUR SYSTEM
> 
> ## turn pppd syslog debugging on
> debug 
> logfile /var/log/vpnlog
> 
> ## change 'servername' to whatever you specify as your server name in chap-secre
> ts
> name *
> lock
> auth
> nobsdcomp
> deflate 0
> refuse-pap
> require-chap
> require-chapms-v2
> +chapms
> +chapms-v2
> proxyarp
> mppe-40
> mppe-128
> mppe-stateless
> ms-dns 213.59.8.8
> ms-dns 192.168.1.1
> 
>                файл options.pptp на клиенте (192.168.1.33)
> lock
> debug
> noauth
> nobsdcomp
> nodeflate
> logfile /var/log/vpnlog
> mppe-40
> mppe-128
> mppe-stateless
> ms-dns 213.59.8.8
> ms-dns 192.168.1.1
> lcp-echo-failure 20
> lcp-echo-interval 20

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


-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re: [Comm] пробл с VPN

[Pavel Sabirjanov]

khudyakov пишет:

>Здравствуйте, Pavel.
>
>Вы писали 14 октября 2004 г., 19:12:55:
>
>PS> max пишет:
>
>  
>
>>>Pavel Sabirjanov пишет:
>>>
>>>      
>>>
>>>>Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
>>>>А из под одного ната у Вас работают 3-4-5 машин?
>>>>Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
>>>>patch-o-matic (www.netfilter.org)
>>>>
>>>>        
>>>>
>>>У меня на клиенте вообще нет /proc/net/ip_conntrack, а что там должно 
>>>быть?
>>>И для чего нужен патч pptp-conntrack-nat?
>>>
>>>      
>>>
>PS> Если у ната, из под которого соединяется более одного клиента, нет 
>PS> хелпер модуля, то на VPN-сервере нужно пропатчить ядро, iptables, и 
>PS> собрать модули ip_conntrack_pptp, ip_conntrack_proto_gre. (я их уже 
>PS> собрал, осталось проверить)
>
>              Спасибо за совет - боюсь только на работающем сервере
>              экспериментировать со сборкой модулей - я этого еще не
>              делал ни разу. Придется наверное обращаться к кому то за
>              помощью. Вопрос - почему проблема возникает только при
>              впн коннекте с машины на линуксе, а с виндов пробл нет -
>              ведь они все в одной сети 192.168.1.0/24 ( и впн сервер
>              тоже)
>  
>
Если у Вас VPN-сервер и клиенты в одной сети 192.168.1.0/24, то боюсь 
что эти модули Вам не помогут.
У Вас я так понял не происходит преобразования адреса при подключении  к 
впн серверу, значит проблема не в этом. Даже не знаю что посоветовать.

-- 
С уважением,
Сабирьянов Павел
pavel@ukr-inter.net

Re: [Comm] пробл с VPN

[max]

Попробуй на клиенте самые простые настройки:
в /etc/ppp/peers/ создаёш файл inet (или как душе угодно)
В нем:
defaultroute
name XXX
, где ХХХ - логин на впн

В /etc/ppp/chap-secrets заносишь логин-пароль на впн с таким 
синтаксисом: login * passwd *

В /etc/ppp/options:
noipdefault
cleardefaultroute

В /etc/resolv.conf заносишь ip адреса днс прова.

Под рутом запускаешь pptp ip-сервера call inet
Всё должно работать.

Это для начала, а дальше крути конфиги как тебе нужно.
-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 18:17:58:

m> khudyakov пишет:

m> У меня было что-то подобное.
m> Файервол должен пропускать протокол gre.
m> Эсли проблема в этом можно легко проверить:
m> tcpdump -i iface или iptraf
m> и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
m> идут.

m> iptables -p 47 -j ACCEPT решит проблему



 Так при коннекте более ста машин на виндах проблем с файрволом то на
 сервере нет..
-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 18:20:40:

m> max пишет:
>> khudyakov пишет:
>> 
>> У меня было что-то подобное.
>> Файервол должен пропускать протокол gre.
>> Эсли проблема в этом можно легко проверить:
>> tcpdump -i iface или iptraf
>> и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
>> идут.
>> 
>> iptables -p 47 -j ACCEPT решит проблему
>> 
m> Загнался немного iptables -A FORWARD -p 47 -j ACCEPT
m> или iptables -A OUTPUT -p 47 -j ACCEPT и iptables -A INPUT -p 47 -j ACCEPT

Так при коннекте более ста машин на виндах проблем с файрволом то на
 сервере нет..

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: [Comm] пробл с VPN

[Michael Holzman]

Я прошу прощения за то, что лезу в дискуссию,  но может ли мне
кто-нибудь объяснить вот эту ошибку на сервере:

> Cannot determine ethernet address for proxy ARP

Спасибо,
  Михаил

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Pavel.

Вы писали 14 октября 2004 г., 18:52:36:

PS> Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
PS> А из под одного ната у Вас работают 3-4-5 машин?
PS> Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
PS> patch-o-matic (www.netfilter.org)

PS> khudyakov пишет:

>>Здравствуйте всем!
>>Столкнулся со следующей проблемой. Не могу соединиться с VPN сервером
>>с линуксовой машины. Сервер работает более года безупречно, все
>>виндовые машины авторизуются и работают также. На сервере RedHat, ядро
>>2.4.22. клиентская машина на AltLinux Master2.2.
>>При попытке коннекта взводятся ppp интерфейсы на сервере и клиенте,
>>проходит авторизация успешно  и потом все....
>>Включил опцию debug  на обеих машинах и получил вот что ( подробнее см
>>.файл). на сервере пишет:
>>
>>
>>Обидноза линукс в том смысле что в винде ничо не надо донастраивать, а
>>здесь темный лес...
>>Конфигурация файлов options сервера и клиента прилагается (в файле).
>>Огромная просьба помочь - в сети есть еще несколько машин на Alt
>>С уважением Худяков Игорь.
>>      
>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Community mailing list
>>Community@altlinux.ru
>>https://lists.altlinux.ru/mailman/listinfo/community
>>

    Дело в том что в сети 140 клиентских машин, из них только 6 на
    линуксе,за год не было проблем с коннектом на 1723 порт



-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Pavel.

Вы писали 14 октября 2004 г., 18:52:36:

PS> Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
PS> А из под одного ната у Вас работают 3-4-5 машин?
PS> Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
PS> patch-o-matic (www.netfilter.org)

PS> khudyakov пишет:

>>Здравствуйте всем!
>>Столкнулся со следующей проблемой. Не могу соединиться с VPN сервером
>>с линуксовой машины. Сервер работает более года безупречно, все
>>виндовые машины авторизуются и работают также. На сервере RedHat, ядро
>>2.4.22. клиентская машина на AltLinux Master2.2.
>>При попытке коннекта взводятся ppp интерфейсы на сервере и клиенте,
>>проходит авторизация успешно  и потом все....
>>Включил опцию debug  на обеих машинах и получил вот что ( подробнее см
>>.файл). на сервере пишет:
>>
>>
>>Обидноза линукс в том смысле что в винде ничо не надо донастраивать, а
>>здесь темный лес...
>>Конфигурация файлов options сервера и клиента прилагается (в файле).
>>Огромная просьба помочь - в сети есть еще несколько машин на Alt
>>С уважением Худяков Игорь.
>>      
>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Community mailing list
>>Community@altlinux.ru
>>https://lists.altlinux.ru/mailman/listinfo/community
>>

       в ip_conntrack нечто подобное что и в логах - пакеты  SYN и SYN
       ACK а  соединение в состояние установленное не переходит.
       на  стороне клиента за 2 минуты с интерфейса ррр уходит пакетов
       до 900 мегабайт в ццелом, а принято 93кб....(может дело в
       маршрутизации?)



-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: Re[2]: [Comm] пробл с VPN

[Michael Holzman]

>         Я  так понимаю - эта ошибка выдается сервером по причине того
>         что в файле options сервера стоит опция proxyarp - надо ее
>         просто отключить - эта ошибка не мешает коннекту - она
>         выдается почти при всех коннектах..
> 
А не может ли быть так, что с форточками не мешает, а с Linux  - мешает?

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 18:58:03:

m> khudyakov пишет:

>> Здравствуйте, max.
>> 
>> Вы писали 14 октября 2004 г., 18:20:40:
>> 
>> m> max пишет:
>> 
>>>>khudyakov пишет:
>>>>
>>>>У меня было что-то подобное.
>>>>Файервол должен пропускать протокол gre.
>>>>Эсли проблема в этом можно легко проверить:
>>>>tcpdump -i iface или iptraf
>>>>и видно что gre пакеты идут только от сервера к клиенту, а от клиента не 
>>>>идут.
>>>>
>>>>iptables -p 47 -j ACCEPT решит проблему
>>>>
>> 
>> m> Загнался немного iptables -A FORWARD -p 47 -j ACCEPT
>> m> или iptables -A OUTPUT -p 47 -j ACCEPT и iptables -A INPUT -p 47 -j ACCEPT
>> 
>> Так при коннекте более ста машин на виндах проблем с файрволом то на
>>  сервере нет..

m> Я про локальный файрвол на клиенте.
m> И tcpdump смотри на клиенте. У меня была в этом проблема, если не то, 
m> другим помочь не смогу.


      На клиенте все ACCEPT. Я исключил влияние iptables на клиенте.
      Посмотрю дамп - правда я это никогда не делал..
-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Pavel.

Вы писали 14 октября 2004 г., 19:03:23:

PS> khudyakov пишет:

>>    Дело в том что в сети 140 клиентских машин, из них только 6 на
>>    линуксе,за год не было проблем с коннектом на 1723 порт
>>
>>  
>>
PS> Значит проблема в клиентской стороне, Вам уже написали что посмотреть.


   Имеется ввиду что проблем не было у машин , кроме линуксовых.
    все политики iptables  на клиенте ACCEPT.

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: [Comm] пробл с VPN

[max]

khudyakov пишет:
> Здравствуйте, max.
> 
> Вы писали 14 октября 2004 г., 19:28:52:
> 
> m> Попробуй на клиенте самые простые настройки:
> m> в /etc/ppp/peers/ создаёш файл inet (или как душе угодно)
> m> В нем:
> m> defaultroute
> m> name XXX
> m> , где ХХХ - логин на впн
> 
> m> В /etc/ppp/chap-secrets заносишь логин-пароль на впн с таким 
> m> синтаксисом: login * passwd *
> 
> m> В /etc/ppp/options:
> m> noipdefault
> m> cleardefaultroute
> 
> m> В /etc/resolv.conf заносишь ip адреса днс прова.
> 
> m> Под рутом запускаешь pptp ip-сервера call inet
> m> Всё должно работать.
> 
> m> Это для начала, а дальше крути конфиги как тебе нужно.
>       Дело в том что такой файл есть и в нем прописан и адрес сервера
>       типа pty "pptp  192.168.1.1 --nolaunch pppd"
>       defaultroute
>       debug
>       ipparam "tun"   ( это имя туннеля)
>        name .....
>        remotename ....
>                  и запускаю я его из rc.local командой pppd call tun
Удали лишние опции и попробуй.

-- 
С наилучшими пожеланиями, Баукин Максим max@zlt.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 19:09:07:

>>        в ip_conntrack нечто подобное что и в логах - пакеты  SYN и SYN
>>        ACK а  соединение в состояние установленное не переходит.
>>        на  стороне клиента за 2 минуты с интерфейса ррр уходит пакетов
>>        до 900 мегабайт в ццелом, а принято 93кб....(может дело в
>>        маршрутизации?)
>> 
m>   Если связь между машинами есть, значит маршрутизация не при чём.
m> Хотя если впн-сервер за шлюзом и используется defaultroute, шлюз 
m> сброситься и клиент будет думать что впн-сервер за ррр-интерфейсом,
m> и связь разорвётся. Такое тоже видел.
m> Пропиши на клиенте статический маршрут до впн-сервера.
m> route add [ip впн-сервер] gw [шлюз] dev [iface шлюза]

       VPN сервер физически находится на шлюзе и в options.pptp на
       клиенте добавлен  дефолтный  маршрут

          файл options на vpn сервере 192.168.1.1
## SAMPLE ONLY
## CHANGE TO SUIT YOUR SYSTEM

## turn pppd syslog debugging on
debug 
logfile /var/log/vpnlog

## change 'servername' to whatever you specify as your server name in chap-secre
ts
name *
lock
auth
nobsdcomp
deflate 0
refuse-pap
require-chap
require-chapms-v2
+chapms
+chapms-v2
proxyarp
mppe-40
mppe-128
mppe-stateless
ms-dns 213.59.8.8
ms-dns 192.168.1.1

               файл options.pptp на клиенте (192.168.1.33)
lock
debug
noauth
nobsdcomp
nodeflate
logfile /var/log/vpnlog
mppe-40
mppe-128
mppe-stateless
ms-dns 213.59.8.8
ms-dns 192.168.1.1
lcp-echo-failure 20
lcp-echo-interval 20
       

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 19:09:07:

>>        в ip_conntrack нечто подобное что и в логах - пакеты  SYN и SYN
>>        ACK а  соединение в состояние установленное не переходит.
>>        на  стороне клиента за 2 минуты с интерфейса ррр уходит пакетов
>>        до 900 мегабайт в ццелом, а принято 93кб....(может дело в
>>        маршрутизации?)
>> 
m>   Если связь между машинами есть, значит маршрутизация не при чём.
m> Хотя если впн-сервер за шлюзом и используется defaultroute, шлюз 
m> сброситься и клиент будет думать что впн-сервер за ррр-интерфейсом,
m> и связь разорвётся. Такое тоже видел.
m> Пропиши на клиенте статический маршрут до впн-сервера.
m> route add [ip впн-сервер] gw [шлюз] dev [iface шлюза]

   пардон - дефолтный маршрут прописан в файле с именем туннеля

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Pavel.

Вы писали 14 октября 2004 г., 19:12:55:

PS> max пишет:

>> Pavel Sabirjanov пишет:
>>
>>> Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
>>> А из под одного ната у Вас работают 3-4-5 машин?
>>> Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
>>> patch-o-matic (www.netfilter.org)
>>>
>> У меня на клиенте вообще нет /proc/net/ip_conntrack, а что там должно 
>> быть?
>> И для чего нужен патч pptp-conntrack-nat?
>>
PS> Если у ната, из под которого соединяется более одного клиента, нет 
PS> хелпер модуля, то на VPN-сервере нужно пропатчить ядро, iptables, и 
PS> собрать модули ip_conntrack_pptp, ip_conntrack_proto_gre. (я их уже 
PS> собрал, осталось проверить)

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


-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Pavel.

Вы писали 14 октября 2004 г., 19:26:32:

PS> khudyakov пишет:

>>Здравствуйте, Pavel.
>>
>>Вы писали 14 октября 2004 г., 19:12:55:
>>
>>PS> max пишет:
>>
>>  
>>
>>>>Pavel Sabirjanov пишет:
>>>>
>>>>      
>>>>
>>>>>Посмотрите что в /proc/net/ip_conntrack при попытке подключится.
>>>>>А из под одного ната у Вас работают 3-4-5 машин?
>>>>>Если нет, то Вам нужно ставить патч pptp-conntrack-nat из пакета 
>>>>>patch-o-matic (www.netfilter.org)
>>>>>
>>>>>        
>>>>>
>>>>У меня на клиенте вообще нет /proc/net/ip_conntrack, а что там должно 
>>>>быть?
>>>>И для чего нужен патч pptp-conntrack-nat?
>>>>
>>>>      
>>>>
>>PS> Если у ната, из под которого соединяется более одного клиента, нет 
>>PS> хелпер модуля, то на VPN-сервере нужно пропатчить ядро, iptables, и 
>>PS> собрать модули ip_conntrack_pptp, ip_conntrack_proto_gre. (я их уже 
>>PS> собрал, осталось проверить)
>>
>>              Спасибо за совет - боюсь только на работающем сервере
>>              экспериментировать со сборкой модулей - я этого еще не
>>              делал ни разу. Придется наверное обращаться к кому то за
>>              помощью. Вопрос - почему проблема возникает только при
>>              впн коннекте с машины на линуксе, а с виндов пробл нет -
>>              ведь они все в одной сети 192.168.1.0/24 ( и впн сервер
>>              тоже)
>>  
>>
PS> Если у Вас VPN-сервер и клиенты в одной сети 192.168.1.0/24, то боюсь 
PS> что эти модули Вам не помогут.
PS> У Вас я так понял не происходит преобразования адреса при подключении  к 
PS> впн серверу, значит проблема не в этом. Даже не знаю что посоветовать.


      Почему не происходит?  вот то что посылает сервер (назначает
      машине 192.168.1.33 адрес 192.168.22.33
rcvd [CHAP Response id=0x1 <f7c60cf40efcdaa1008975c810bd916900000000000000009c71
d709c53cf2941e9601132411b1d284ad65bd640d6e1800>, name = "Goshik"]
sent [CHAP Success id=0x1 "S=A9C96D2B40F1217D4CE96938D3D7C409B671FEA2"]
sent [IPCP ConfReq id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>] 
sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
MSCHAP-v2 peer authentication succeeded for Goshik
rcvd [IPCP ConfReq id=0x1 <addr 192.168.1.33> <compress VJ 0f 01>]
sent [IPCP ConfNak id=0x1 <addr 192.168.22.33>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
sent [CCP ConfRej id=0x1 <mppe 1 0 0 40>]
rcvd [IPCP ConfAck id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
sent [CCP ConfReq id=0x2]
rcvd [IPCP ConfReq id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
Cannot determine ethernet address for proxy ARP
local  IP address 192.168.1.1
remote IP address 192.168.22.33
                   А вот что получает клиент - он принимает этот
                   192.168.22.33
sent [LCP EchoReq id=0x0 magic=0x3457df24]
rcvd [CHAP Challenge id=0x1 <4d4ff8a58b0443c618c9dcbb404c2e9b>, name = "*"]
sent [CHAP Response id=0x1 <f7c60cf40efcdaa1008975c810bd916900000000000000009c71
d709c53cf2941e9601132411b1d284ad65bd640d6e1800>, name = "Goshik"]
rcvd [LCP EchoRep id=0x0 magic=0x187d49c8]
rcvd [CHAP Success id=0x1 "S=A9C96D2B40F1217D4CE96938D3D7C409B671FEA2"]
Remote message: S=A9C96D2B40F1217D4CE96938D3D7C409B671FEA2
sent [IPCP ConfReq id=0x1 <addr 192.168.1.33> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <mppe 1 0 0 60]
rcvd [IPCP ConfReq id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x1 <addr 192.168.1.1> <compress VJ 0f 01>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 60]
sent [CCP ConfNak id=0x1 <mppe 1 0 0 40]
rcvd [IPCP ConfNak id=0x1 <addr 192.168.22.33>]
sent [IPCP ConfReq id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
rcvd [CCP ConfRej id=0x1 <mppe 1 0 0 40]
sent [CCP ConfReq id=0x2]
rcvd [CCP ConfReq id=0x2]
sent [CCP ConfAck id=0x2]
rcvd [IPCP ConfAck id=0x2 <addr 192.168.22.33> <compress VJ 0f 01>]
local  IP address 192.168.22.33
remote IP address 192.168.1.1
Script /etc/ppp/ip-up started (pid 3447
                   

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 19:28:52:

m> Попробуй на клиенте самые простые настройки:
m> в /etc/ppp/peers/ создаёш файл inet (или как душе угодно)
m> В нем:
m> defaultroute
m> name XXX
m> , где ХХХ - логин на впн

m> В /etc/ppp/chap-secrets заносишь логин-пароль на впн с таким 
m> синтаксисом: login * passwd *

m> В /etc/ppp/options:
m> noipdefault
m> cleardefaultroute

m> В /etc/resolv.conf заносишь ip адреса днс прова.

m> Под рутом запускаешь pptp ip-сервера call inet
m> Всё должно работать.

m> Это для начала, а дальше крути конфиги как тебе нужно.
      Дело в том что такой файл есть и в нем прописан и адрес сервера
      типа pty "pptp  192.168.1.1 --nolaunch pppd"
      defaultroute
      debug
      ipparam "tun"   ( это имя туннеля)
       name .....
       remotename ....
                 и запускаю я его из rc.local командой pppd call tun

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, max.

Вы писали 14 октября 2004 г., 19:28:52:

m> Попробуй на клиенте самые простые настройки:
m> в /etc/ppp/peers/ создаёш файл inet (или как душе угодно)
m> В нем:
m> defaultroute
m> name XXX
m> , где ХХХ - логин на впн

m> В /etc/ppp/chap-secrets заносишь логин-пароль на впн с таким 
m> синтаксисом: login * passwd *

m> В /etc/ppp/options:
m> noipdefault
m> cleardefaultroute

m> В /etc/resolv.conf заносишь ip адреса днс прова.

m> Под рутом запускаешь pptp ip-сервера call inet
m> Всё должно работать.

m> Это для начала, а дальше крути конфиги как тебе нужно.

       Оно запускается - чему подтверждение - логи, но потом с обоих
       сторон только sent... а приема нет в результате "зависание
       модема"

-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Michael.

Вы писали 14 октября 2004 г., 19:55:41:

MH> Я прошу прощения за то, что лезу в дискуссию,  но может ли мне
MH> кто-нибудь объяснить вот эту ошибку на сервере:

>> Cannot determine ethernet address for proxy ARP

MH> Спасибо,
MH>   Михаил
 
        Я  так понимаю - эта ошибка выдается сервером по причине того
        что в файле options сервера стоит опция proxyarp - надо ее
        просто отключить - эта ошибка не мешает коннекту - она
        выдается почти при всех коннектах..


-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: Re[2]: [Comm] пробл с VPN

[Michael Holzman]

> >         Я  так понимаю - эта ошибка выдается сервером по причине того
> >         что в файле options сервера стоит опция proxyarp - надо ее
> >         просто отключить - эта ошибка не мешает коннекту - она
> >         выдается почти при всех коннектах..
> > 
> А не может ли быть так, что с форточками не мешает, а с Linux  - мешает?
> 
Тут в параллельном разговоре промелькнула ссылка
http://poptop.sourceforge.net/dox/qna.html#2

Там есть промежуточное решение  proxy-arp проблемы. 

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

Re[4]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Michael.

Вы писали 14 октября 2004 г., 20:06:25:

>>         Я  так понимаю - эта ошибка выдается сервером по причине того
>>         что в файле options сервера стоит опция proxyarp - надо ее
>>         просто отключить - эта ошибка не мешает коннекту - она
>>         выдается почти при всех коннектах..
>> 
MH> А не может ли быть так, что с форточками не мешает, а с Linux  - мешает?
 
        пробовал - не помогает


-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: [Comm] пробл с VPN

[Alexander Vasiliev]

On Thu, Oct 14, 2004 at 08:44:22PM +1200, khudyakov wrote:
> 
>        Оно запускается - чему подтверждение - логи, но потом с обоих
>        сторон только sent... а приема нет в результате "зависание
>        модема"
> 
Похоже проблема с маршрутизацией.
После запуска pptp нужно оставить старый маршрут на pptp сервер
(чтобы GRE-туннель работал).
Все остальное пустить через новый default route.

На Windows это делаетс при установке соединения.
На Linux'е

#!/bin/sh

route add -host PPTP-SERVER gw OLD-GW
route add default gw NEW-GW
route del default gw OLD-GW

--
 Александр Васильев
 ЗАО "Таском"
 vav@tascom.ru

Re[2]: [Comm] пробл с VPN

[khudyakov]

Здравствуйте, Alexander.

Вы писали 15 октября 2004 г., 18:29:11:

AV> On Thu, Oct 14, 2004 at 08:44:22PM +1200, khudyakov wrote:
>> 
>>        Оно запускается - чему подтверждение - логи, но потом с обоих
>>        сторон только sent... а приема нет в результате "зависание
>>        модема"
>> 
AV> Похоже проблема с маршрутизацией.
AV> После запуска pptp нужно оставить старый маршрут на pptp сервер
AV> (чтобы GRE-туннель работал).
AV> Все остальное пустить через новый default route.

AV> На Windows это делаетс при установке соединения.
AV> На Linux'е

AV> #!/bin/sh

AV> route add -host PPTP-SERVER gw OLD-GW
AV> route add default gw NEW-GW
AV> route del default gw OLD-GW

AV> --
AV>  Александр Васильев
AV>  ЗАО "Таском"
AV>  vav@tascom.ru
AV> _______________________________________________
AV> Community mailing list
AV> Community@altlinux.ru
AV> https://lists.altlinux.ru/mailman/listinfo/communit
Здравствуйте - а почему OLD и NEW?? шлюз как был на 192.168.1.1 так и
остался
то есть первая запись будет route add -host 192.168.1.1 gw
192.168.1.1???
Следующее - старый дефолтный маршрут надо удалять до начала соединения
- иначе pptp не сможет установить свой defaultroute    (2 defaultroute
 быть не может)


-- 
С уважением,
 khudyakov                          mailto:khudyakov@ankam26.ru

Re: [Comm] пробл с VPN

[Alexander Vasiliev]

On Fri, Oct 15, 2004 at 08:51:55PM +1200, khudyakov wrote:
> 
> AV> #!/bin/sh
> 
> AV> route add -host PPTP-SERVER gw OLD-GW
> AV> route add default gw NEW-GW
> AV> route del default gw OLD-GW
> 
Все вышенаписанное я поместил в /etc/ppp/ip-up.local
Этот файл выполняется при поднятии pptp соединения.

> Здравствуйте - а почему OLD и NEW?? шлюз как был на 192.168.1.1 так и
> остался
> то есть первая запись будет route add -host 192.168.1.1 gw
> 192.168.1.1???
По-видимому, в вашем случае, нет.
У меня pptp-server имеет ip совсем из другой сети (отличной от
сети OLD-GW). И выдает ip для туннеля не совпадающий с
PPTP-SERVER.
В вашей ситуации указывать маршрут на 192.168.1.1 не надо, ведь
клиент и сервер находятся в одной сети (client ip 192.168.1.33),
а новый default route нужно прописать не только на ip, а и на
интерфейс:

route add default gw 192.168.1.1 dev ppp0

> Следующее - старый дефолтный маршрут надо удалять до начала соединения
> - иначе pptp не сможет установить свой defaultroute    (2 defaultroute
>  быть не может)

И не забудьте вернуть все обратно после закрытия pptp сеанса.
Можно для этого использовать /etc/ppp/ip-down.local.
--
 Александр Васильев
 ЗАО "Таском"
 vav@tascom.ru