URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID10
Нить номер: 1097
[ Назад ]

Исходное сообщение
"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 11:40

Нужно соединить филиалы через VPN.
Установил MPD.
Из одного филиала все пучком работает, а другой подключить не могу. При подключении на клиенте выдается ошибка 619 - указанный порт не подключен. Смотрю в логи на сервере, там где соединения удаются они идут по портам порядка 1000. А где ошибка - по портам 62000-64000.
А от чего зависит по какому порту идет обращение к VPN серверу?
Разница между филиалами в том, что там где ошибка чтобы получить выход в инет они сначала конектятся к провайдеру тоже через VPN.
Хотя само по себе такой вариант не должен помешать. Вполне возможно, что у провайдера стоят какие-то фильтры или порты может какие прикрыты. Можно ли как-нибудь проанализировать ситуацию и понять, затык в настройках у провайдера или у меня руки кривые.
Спросить что-либо у провайдера нельзя они вообще ни на какие технические вопросы по устройству их сети не отвечают.
(Как то нужно было сменить компьютер, так я полдня потерял прежде чем понял что у них установлена привязка к MAC адресам :((( )

Содержание

VPN, MPD, ошибка 619,Xela, 11:59 , 14-Янв-04
- VPN, MPD, ошибка 619,ЕйСи, 12:08 , 14-Янв-04
  - VPN, MPD, ошибка 619,Xela, 12:12 , 14-Янв-04
    - VPN, MPD, ошибка 619,ЕйСи, 12:47 , 14-Янв-04
      - VPN, MPD, ошибка 619,Xela, 12:53 , 14-Янв-04
        
        VPN, MPD, ошибка 619,ЕйСи, 13:07 , 14-Янв-04
        
        VPN, MPD, ошибка 619,Xela, 13:16 , 14-Янв-04
        
        VPN, MPD, ошибка 619,ЕйСи, 13:40 , 14-Янв-04
        VPN, MPD, ошибка 619,ЕйСи, 13:44 , 14-Янв-04
        
        VPN, MPD, ошибка 619,Xela, 14:28 , 14-Янв-04
        VPN, MPD, ошибка 619,Xela, 14:29 , 14-Янв-04

Сообщения в этом обсуждении

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 11:59

коннект к VPN в случае с PPTP идет по порту 1723
cat /etc/services| grep ppt
pptp 1723/tcp #Point-to-point tunnelling protocol
После инициации весь трафик идет по протоколу GRE
cat /etc/protocols| grep GRE
gre 47 GRE # Generic Routing Encapsulation
Если что-то из этого режется --- нифига не выдет.

"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 12:08

>коннект к VPN в случае с PPTP идет по порту 1723
>
>cat /etc/services| grep ppt
>pptp
>1723/tcp   #Point-to-point tunnelling protocol
>
>После инициации весь трафик идет по протоколу GRE
>cat /etc/protocols| grep GRE
>gre     47      GRE
>
> # Generic Routing Encapsulation
>
>Если что-то из этого режется --- нифига не выдет.
А как-нибудь можно понять, установленны ли данные ограничения у провайдера?

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 12:12

tcpdump тебе в руки
tcpdump -i ed0 -p proto 47 or port 1723

"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 12:47

>tcpdump тебе в руки
>
>tcpdump -i ed0 -p proto 47 or port 1723
tcpdump показывал пакеты только на 47, на 1723 вообще ничего не происходит и в случае успешного коннекта и в случае ошибки.
Разница же в показаниях по 47 порту в том, что там где соединение не удается фиксируются только пакеты от меня к клиенту. А там где нормально пакеты идут в обе стороны
Вот лог mpd (в случае ошибки):
Jan 14 12:28:57 stat mpd: mpd: PPTP connection from 62.205.168.11:64752
Jan 14 12:28:57 stat mpd: pptp0: attached to connection with 62.205.168.11:64752
Jan 14 12:28:57 stat mpd: [pptp2] IFACE: Open event
Jan 14 12:28:57 stat mpd: [pptp2] IPCP: Open event
Jan 14 12:28:57 stat mpd: [pptp2] IPCP: state change Initial --> Starting
Jan 14 12:28:57 stat mpd: [pptp2] IPCP: LayerStart
Jan 14 12:28:57 stat mpd: [pptp2] IPCP: Open event
Jan 14 12:28:57 stat mpd: [pptp2] bundle: OPEN event in state CLOSED
Jan 14 12:28:57 stat mpd: [pptp2] opening link "pptp2"...
Jan 14 12:28:57 stat mpd: [pptp2] link: OPEN event
Jan 14 12:28:57 stat mpd: [pptp2] LCP: Open event
Jan 14 12:28:57 stat mpd: [pptp2] LCP: state change Initial --> Starting
Jan 14 12:28:57 stat mpd: [pptp2] LCP: LayerStart
Jan 14 12:28:57 stat mpd: [pptp2] device: OPEN event in state DOWN
Jan 14 12:28:57 stat mpd: [pptp2] attaching to peer's outgoing call
Jan 14 12:28:57 stat mpd: [pptp2] device is now in state OPENING
Jan 14 12:28:57 stat mpd: [pptp2] device: UP event in state OPENING
Jan 14 12:28:57 stat mpd: [pptp2] device is now in state UP
Jan 14 12:28:57 stat mpd: [pptp2] link: UP event
Jan 14 12:28:57 stat mpd: [pptp2] link: origination is remote
Jan 14 12:28:57 stat mpd: [pptp2] LCP: Up event
Jan 14 12:28:57 stat mpd: [pptp2] LCP: state change Starting --> Req-Sent
Jan 14 12:28:57 stat mpd: [pptp2] LCP: phase shift DEAD --> ESTABLISH
Jan 14 12:28:57 stat mpd: [pptp2] LCP: SendConfigReq #123
Jan 14 12:28:57 stat mpd:  ACFCOMP
Jan 14 12:28:57 stat mpd:  PROTOCOMP
Jan 14 12:28:57 stat mpd:  MRU 1500
Jan 14 12:28:57 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:28:57 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:28:57 stat mpd: pptp0-0: ignoring SetLinkInfo
Jan 14 12:28:59 stat mpd: [pptp2] LCP: SendConfigReq #124
Jan 14 12:28:59 stat mpd:  ACFCOMP
Jan 14 12:28:59 stat mpd:  PROTOCOMP
Jan 14 12:28:59 stat mpd:  MRU 1500
Jan 14 12:28:59 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:28:59 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:01 stat mpd: [pptp2] LCP: SendConfigReq #125
Jan 14 12:29:01 stat mpd:  ACFCOMP
Jan 14 12:29:01 stat mpd:  PROTOCOMP
Jan 14 12:29:01 stat mpd:  MRU 1500
Jan 14 12:29:01 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:01 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:03 stat mpd: [pptp2] LCP: SendConfigReq #126
Jan 14 12:29:03 stat mpd:  ACFCOMP
Jan 14 12:29:03 stat mpd:  PROTOCOMP
Jan 14 12:29:03 stat mpd:  MRU 1500
Jan 14 12:29:03 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:03 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:05 stat mpd: [pptp2] LCP: SendConfigReq #127
Jan 14 12:29:05 stat mpd:  ACFCOMP
Jan 14 12:29:05 stat mpd:  PROTOCOMP
Jan 14 12:29:05 stat mpd:  MRU 1500
Jan 14 12:29:05 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:05 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:07 stat mpd: [pptp2] LCP: SendConfigReq #128
Jan 14 12:29:07 stat mpd:  ACFCOMP
Jan 14 12:29:07 stat mpd:  PROTOCOMP
Jan 14 12:29:07 stat mpd:  MRU 1500
Jan 14 12:29:07 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:07 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:09 stat mpd: [pptp2] LCP: SendConfigReq #129
Jan 14 12:29:09 stat mpd:  ACFCOMP
Jan 14 12:29:09 stat mpd:  PROTOCOMP
Jan 14 12:29:09 stat mpd:  MRU 1500
Jan 14 12:29:09 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:09 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:11 stat mpd: [pptp2] LCP: SendConfigReq #130
Jan 14 12:29:11 stat mpd:  ACFCOMP
Jan 14 12:29:11 stat mpd:  PROTOCOMP
Jan 14 12:29:11 stat mpd:  MRU 1500
Jan 14 12:29:11 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:11 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:13 stat mpd: [pptp2] LCP: SendConfigReq #131
Jan 14 12:29:13 stat mpd:  ACFCOMP
Jan 14 12:29:13 stat mpd:  PROTOCOMP
Jan 14 12:29:13 stat mpd:  MRU 1500
Jan 14 12:29:13 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:13 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:15 stat mpd: [pptp2] LCP: SendConfigReq #132
Jan 14 12:29:15 stat mpd:  ACFCOMP
Jan 14 12:29:15 stat mpd:  PROTOCOMP
Jan 14 12:29:15 stat mpd:  MRU 1500
Jan 14 12:29:15 stat mpd:  MAGICNUM ef4aa74e
Jan 14 12:29:15 stat mpd:  AUTHPROTO CHAP MSOFT
Jan 14 12:29:17 stat mpd: [pptp2] LCP: state change Req-Sent --> Stopped
Jan 14 12:29:17 stat mpd: [pptp2] LCP: LayerFinish
Jan 14 12:29:17 stat mpd: [pptp2] LCP: parameter negotiation failed
Jan 14 12:29:17 stat mpd: [pptp2] LCP: LayerFinish
Jan 14 12:29:17 stat mpd: [pptp2] device: CLOSE event in state UP
Jan 14 12:29:17 stat mpd: pptp0-0: clearing call
Jan 14 12:29:17 stat mpd: pptp0-0: killing channel
Jan 14 12:29:17 stat mpd: [pptp2] PPTP call terminated
Jan 14 12:29:17 stat mpd: [pptp2] IFACE: Close event
Jan 14 12:29:17 stat mpd: [pptp2] IPCP: Close event
Jan 14 12:29:17 stat mpd: [pptp2] IPCP: state change Starting --> Initial
Jan 14 12:29:17 stat mpd: [pptp2] IPCP: LayerFinish
Jan 14 12:29:17 stat mpd: [pptp2] IFACE: Close event
Jan 14 12:29:17 stat mpd: pptp0: closing connection with 62.205.168.11:64752
Jan 14 12:29:17 stat mpd: [pptp2] IFACE: Close event
Jan 14 12:29:17 stat mpd: [pptp2] device is now in state CLOSING
Jan 14 12:29:17 stat mpd: [pptp2] bundle: CLOSE event in state OPENED
Jan 14 12:29:17 stat mpd: [pptp2] closing link "pptp2"...
Jan 14 12:29:17 stat mpd: [pptp2] device: CLOSE event in state CLOSING
Jan 14 12:29:17 stat mpd: [pptp2] device is now in state CLOSING
Jan 14 12:29:17 stat mpd: [pptp2] link: CLOSE event
Jan 14 12:29:17 stat mpd: [pptp2] LCP: Close event
Jan 14 12:29:17 stat mpd: [pptp2] LCP: state change Stopped --> Closed
Jan 14 12:29:17 stat mpd: [pptp2] device: DOWN event in state CLOSING
Jan 14 12:29:17 stat mpd: [pptp2] device is now in state DOWN
Jan 14 12:29:17 stat mpd: [pptp2] link: DOWN event
Jan 14 12:29:17 stat mpd: [pptp2] LCP: Down event
Jan 14 12:29:17 stat mpd: [pptp2] LCP: state change Closed --> Initial
Jan 14 12:29:17 stat mpd: [pptp2] LCP: phase shift ESTABLISH --> DEAD
Jan 14 12:29:17 stat mpd: [pptp2] device: DOWN event in state DOWN
Jan 14 12:29:17 stat mpd: [pptp2] device is now in state DOWN
Jan 14 12:29:17 stat mpd: [pptp2] link: DOWN event
Jan 14 12:29:17 stat mpd: [pptp2] LCP: Down event
Jan 14 12:29:17 stat mpd: pptp0: invalid length 16 for type 4
Jan 14 12:29:17 stat mpd: pptp0: killing connection with 62.205.168.11:64752

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 12:53

Стало быть от клиента не едет GRE --- пинать провайдера клиента.

"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 13:07

>Стало быть от клиента не едет GRE --- пинать провайдера клиента.
Их сисадмин сказал, что у них все открыто. Единственное предположение, что занят стандартный (?) порт для VPN, т.к. уже одно соединение установлено и второй коннект уже ко мне не проходит, т.к. порт тот же самый ???? -Это все со слов админа провайдера!

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 13:16

>второй коннект уже ко мне не проходит, т.к. порт тот же
>самый ???? -Это все со слов админа провайдера!
Полная чушь! Ну подумай сам, как, например, апач работает????
Он же тоже, на одном порту(80) и это не означает что к нему сможет
обратиться только один клиент.
Если у провайдера твой клиент за NAT-ом, то надо прокидывать через NAT GRE.

Скажи провайдеру это магичесокое слово --- GRE.
Это никоем образом не относиться к TCP. Пусть копают в эту строну.
Других вариантов нет и быть не может.
Сам, лично сталкивался с таким. На файрволе, который был под линухом, для нормальной работы с VPN(PPTP) через NAT приходилось подгружать connection tracking модуль для GRE.
А если у прова в качестве файрвола стоит Checkpoint то о VPN можете забыть совсем.

"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 13:40

>Если у провайдера твой клиент за NAT-ом, то надо прокидывать через NAT
>GRE.
>
Т.е divert 8668 ip from any to any via rl0
не достаточно, а какую тогда запись надо добавить в правила, чтобы GRE пропускалось

"VPN, MPD, ошибка 619"
Отправлено ЕйСи , 14-Янв-04 13:44

>>второй коннект уже ко мне не проходит, т.к. порт тот же
>>самый ???? -Это все со слов админа провайдера!
>Полная чушь! Ну подумай сам, как, например, апач работает????
>Он же тоже, на одном порту(80) и это не означает что к
>нему сможет
>обратиться только один клиент.
Пример с апачем немного не подходит, там обращение м.б. с нескольких клиентов, но к одному и тому же серверу. А тут, например клиент посылает пакет по 47 порту, вроде как мне, а получает то его VPN-сервер провайдера. Так не может быть? И если так, то нельзя ли как нибудь сменить этот порт на др. значение

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 14:28

47 --- это не порт. Это тако

"VPN, MPD, ошибка 619"
Отправлено Xela , 14-Янв-04 14:29

47 -- это не порт. Это номер протокола. Не путать с портами TCP/UDP.
Это совсем другое.