Jump to content
  • 0
d1m4n

Аэрокинетик и проблемы с PPTP сервером на нем.

Question

Всем доброго дня!

Имеем: Zyxel Keenetic Air, говорящий в WEB интерфейсе Версия NDMSv2.08(ABGG.0)C1.

Сконфигурирован через веб-морду. Включен PPTP VPN сервер, прописан пользователь с разрешениями авторизовываться на этом сервере, к его аккаунту привязан IP из пула адресов, выдаваемых при подключении.

В этот адрес прописан статический роут с опцией auto (по другому не дает) к подсети за клиентом. Клиент - FreeBSD + mpd5. Фря настроена, как роутер удаленной сети. После подключения на фре имеем:

# ifconfig
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1344
        inet 172.16.123.3 --> 192.168.123.1 netmask 0xffffffff
  
# netstat -nr
192.168.123.0/24   192.168.123.1      UGS         0        0    ng0
192.168.123.1      link#21            UH          0    31054    ng0
  
# ping 192.168.123.1
PING 192.168.123.1 (192.168.123.1): 56 data bytes
64 bytes from 192.168.123.1: icmp_seq=0 ttl=64 time=4.464 ms

# ping -S 192.168.0.1 192.168.123.1
PING 192.168.123.1 (192.168.123.1) from 192.168.0.1: 56 data bytes
^C
--- 192.168.123.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
  
# cat /usr/local/etc/mpd5/mpd.conf
default:
                load pptp_client

pptp_client:
                create bundle static B1
                set iface route 192.168.123.0/24
                set ipcp ranges 0.0.0.0/0 0.0.0.0/0

                set bundle enable compression
                set bundle enable encryption
                set ccp yes mppc
                set mppc no e40
                set mppc yes e128
                set mppc yes stateless

                create link static L1 pptp
                set link action bundle B1
                set auth authname xxxxxxx
                set auth password XXXXXXXXXX
                set link max-redial 0
                set link mtu 1460
                set link keep-alive 20 75
                set pptp peer 77.37.XXX.XXX
                set pptp disable windowing
                open

Очевидно, что на стороне зухеля в сегменте Home прописана подсеть 192.168.123.0/24, а на стороне фри 192.168.0.0/24.

Статик, выдаваемый при подключении по PPTP зухелем - 172.16.123.3.

Проблема: после подключения клиента по PPTP зухель не поднимает роут к удаленной сети.

При этом в логах летающего кинетика и в консоли наблюдается следующее:

I [Apr 12 14:56:57] ndm: kernel: Fast VPN ctrl: setup for src 195.96.XXX.XXX
I [Apr 12 14:56:57] pptpd[10199]: CTRL: Starting call (launching pppd, opening
                    GRE)
I [Apr 12 14:56:57] pptp[10200]: Plugin pptp.so loaded.
I [Apr 12 14:56:57] pptp[10200]: PPTP plugin version 0.8.3 compiled against
                    pppd 2.4.4-4
I [Apr 12 14:56:57] pptp[10200]: pppd 2.4.4-4 started by root, uid 0
I [Apr 12 14:56:57] pptp[10200]: Using interface vpn0
I [Apr 12 14:56:57] pptp[10200]: Connect: vpn0 <--> pptp (195.96.XXX.XXX)
E [Apr 12 14:56:57] pptpd[10199]: CTRL: Ignored a SET LINK INFO packet with
                    real ACCMs!
I [Apr 12 14:56:57] pptp[10200]: MPPE 128-bit stateless compression enabled
I [Apr 12 14:56:59] pptp[10200]: local  IP address 192.168.123.1
I [Apr 12 14:56:59] pptp[10200]: remote IP address 172.16.123.3
W [Apr 12 14:56:59] ndm: Network::RoutingTable: gateway is unreachable, route
                    pending.

Возникает резонный вопрос - а где же ты есть   interface vpn0 и что при подключении по PPTP к нему биндится? У меня нет ответа:

(config)> show ip route
================================================================================
Destination          Gateway           Interface                         Metric
================================================================================
0.0.0.0/0            77.37.192.1       ISP                               0
10.1.30.0/24         0.0.0.0           Guest                             0
77.37.192.0/22       0.0.0.0           ISP                               0
77.37.251.33/32      77.37.192.1       ISP                               0
77.37.255.30/32      77.37.192.1       ISP                               0
172.16.123.3/32      0.0.0.0           VPN                               0
192.168.123.0/24     0.0.0.0           Home                              0
(config)> show in

        interface - display interface status

(config)> show interface

 Usage template:
        interface [{name}]

   Choose:
            FastEthernet0
          FastEthernet0/0
                        0
          FastEthernet0/1
                        1
              WifiMaster0
 WifiMaster0/AccessPoint2
 WifiMaster0/AccessPoint1
                GuestWiFi
 WifiMaster0/AccessPoint0
              AccessPoint
 WifiMaster0/AccessPoint3
 WifiMaster0/WifiStation0
              WifiMaster1
 WifiMaster1/AccessPoint0
           AccessPoint_5G
 WifiMaster1/WifiStation0
      FastEthernet0/Vlan1
      FastEthernet0/Vlan2
                      ISP
      FastEthernet0/Vlan3
                  Bridge0
                     Home
                  Bridge1
                    Guest

(config)> show interface Home

               id: Bridge0
            index: 0
             type: Bridge
      description: Home network
   interface-name: Home
             link: up
        connected: yes
            state: up
              mtu: 1500
         tx-queue: 1000
          address: 192.168.123.1
             mask: 255.255.255.0
           uptime: 146342
           global: no
   security-level: private
              mac: e4:18:6b:24:xx:xx
        auth-type: none

(config)> show interface vpn0
Command::Base error[7405602]: argument parse error.
(config)> show interface VPN
Command::Base error[7405602]: argument parse error.
(config)>
(config)>
(config)> show interface ISP

               id: FastEthernet0/Vlan2
            index: 2
             type: Vlan
      description: Broadband connection
   interface-name: ISP
             link: up
        connected: yes
            state: up
              mtu: 1500
         tx-queue: 1000
          address: 77.37.192.XXX
             mask: 255.255.252.0
           uptime: 146552
           global: yes
        defaultgw: yes
         priority: 700
   security-level: public
              mac: e4:18:6b:24:xx:xx
        auth-type: none

(config)>

На этом полет моей фантазии закончился...

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

Однако дивайс куплен и уже работает, так что нужно решать задачу, как есть.

З.Ы. IPSEC не хочу. Ну вот, блин, просто не хочу и все! Хочу, чтобы PPTP работал "из коробки" и без бубнов...

Буду признателен за любые дельные советы!

З.З.Ы. Вариант "убить себя головой об стену с разбега" не рассматривается. =)

 

   

Share this post


Link to post
Share on other sites

22 answers to this question

Recommended Posts

  • 0
ip route 192.168.0.0 255.255.255.0 172.16.123.3 Home auto

Вот Home не надо. Интерфейс vpnX в оболочке не отображается, поэтому просто

ip route 192.168.0.0 255.255.255.0 172.16.123.3 auto

Share this post


Link to post
Share on other sites
  • 0

2 ndm:

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

Спасибо!

Share this post


Link to post
Share on other sites
  • 0

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

Никак не могу  побороть  похожую проблему. Имеется Ultra c прошивкой 2.10 (пробовал и на  более ранних - тоже самое) и  настроенным pptp сервером согласно рекомендациям https://help.keenetic.net/hc/ru/articles/213967889-

Клиент - Lede 17.01.4.  VPN поднимается (пока без шифрования, но это отдельная  тема) и  маршруты настроены  в  обе  стороны.  Со стороны Lede  есть полный  доступ к устройствам  в локальную  подсеть  Ultra, а  вот  из сети Ultra доступа к локальной подсети за Lede  нет.  Самое  интересное что  маршрут в локальную  сеть LEDE есть и  все хосты в ней   отлично пингуются из терминала на Ультре, однако не проходят  если  делать это с хоста  в локальной сети Ультры....  

Пожалуйста помогите  советом.

(config)> show ip route
================================================================================
Destination          Gateway           Interface                         Metric  
================================================================================
0.0.0.0/0            10.189.152.1      ISP                               0       
10.1.30.0/24         0.0.0.0           Guest                             0       
10.189.152.0/24      0.0.0.0           ISP                               0       
172.16.1.34/32       0.0.0.0           VPN                               0       
192.168.1.0/24       0.0.0.0           Home                              0       
192.168.3.0/24       172.16.1.34       VPN                               0    

 

 

(tools)> ping 192.168.3.1
sending ICMP ECHO request to 192.168.3.1...
PING 192.168.3.1 (192.168.3.1) 56 (84) bytes of data.
84 bytes from 192.168.3.1: icmp_req=1, ttl=64, time=480.93 ms.
84 bytes from 192.168.3.1: icmp_req=2, ttl=64, time=494.98 ms.
84 bytes from 192.168.3.1: icmp_req=3, ttl=64, time=531.06 ms.
84 bytes from 192.168.3.1: icmp_req=4, ttl=64, time=586.28 ms.
84 bytes from 192.168.3.1: icmp_req=5, ttl=64, time=537.50 ms.
84 bytes from 192.168.3.1: icmp_req=6, ttl=64, time=469.50 ms.
--- 192.168.3.1 ping statistics ---
7 packets transmitted, 6 packets received, 14% packet loss,
0 duplicate(s), time 6172.91 ms.
Round-trip min/avg/max = 469.50/516.70/586.28 ms.


 

Спасибо

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0
10 минут назад, denisy сказал:

пингуются из терминала на Ультре, однако не проходят  если  делать это с хоста  в локальной сети Ультры....

А на удаленном роутере маршрут в локальную сеть ультры через туннель есть-то? Или включить "ip nat vpn" на ультре..

Share this post


Link to post
Share on other sites
  • 0
Только что, KorDen сказал:

А на удаленном роутере маршрут в локальную сеть ультры через туннель есть-то? Или включить "ip nat vpn" на ультре..

да, они  автоматически там поднимаются и проблем  с доступом к локальной  сети Ультры не  наблюдается.   пробую ip nat vpn  ...  спасибо за ответ...  отпишусь

Share this post


Link to post
Share on other sites
  • 0

судя по всему  инструкция  ip nat vpn  эквивалентна галке  в  веб интерфейсе Транслировать адреса клиентов (NAT) 

я  пробовал и так и эдак  но результат один :(  -  из локальной сети Ультры пинги не проходят  

Share this post


Link to post
Share on other sites
  • 0

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

Dec  7 23:32:00 ndm: kernel: Fast VPN ctrl: setup for src 176.59.7.84
Dec  7 23:32:00 pptpd[10688]: CTRL: Starting call (launching pppd, opening GRE)
Dec  7 23:32:00 pptp[10690]: Plugin pptp.so loaded.
Dec  7 23:32:00 pptp[10690]: PPTP plugin version 0.8.3 compiled against pppd 2.4.4-4
Dec  7 23:32:00 pptp[10690]: pppd 2.4.4-4 started by root, uid 0
Dec  7 23:32:00 pptp[10690]: using channel 4
Dec  7 23:32:00 pptp[10690]: Using interface vpn0
Dec  7 23:32:00 pptp[10690]: Connect: vpn0 <--> pptp (176.59.7.84)
[E] Dec  7 23:32:06 pptp[10690]: MPPE required but cannot negotiate MPPE key length
Dec  7 23:32:06 pptp[10690]: local  IP address 192.168.1.1
Dec  7 23:32:06 pptp[10690]: remote IP address 172.16.1.34

Share this post


Link to post
Share on other sites
  • 0

 

Нарыл еще ошибку с IPV6 (не настроено на обоих устройствах, по видимому LEDE пытается получить  IPV6 адрес...). Может это быть причиной  почему IPV4  маршрутизация  не работает? Прикрепил self-test (там должны быть следы моих попыток открыть сайт http://192.168.3.1  а  так же пинг на  него из локальной  сети (оба  без ответа), а  так же пингн из терминала Ултры - успешно.

 

Dec  8 19:27:02 pptpd[649]: MGR: Launching /usr/sbin/pptpctrl to handle client
Dec  8 19:27:02 pptpd[649]: CTRL: local address = 192.168.1.1
Dec  8 19:27:02 pptpd[649]: CTRL: remote address = 172.16.1.33
Dec  8 19:27:02 pptpd[649]: CTRL: pppd options file = /var/run/vpnserver/options.pptpd
Dec  8 19:27:02 pptpd[649]: CTRL: Client 176.59.8.66 control connection started
Dec  8 19:27:02 pptpd[649]: CTRL: Received PPTP Control Message (type: 1)
Dec  8 19:27:02 pptpd[649]: CTRL: Made a START CTRL CONN RPLY packet
Dec  8 19:27:02 pptpd[649]: CTRL: I wrote 156 bytes to the client.
Dec  8 19:27:02 pptpd[649]: CTRL: Sent packet to client
Dec  8 19:27:03 pptpd[649]: CTRL: Received PPTP Control Message (type: 7)
Dec  8 19:27:03 pptpd[649]: CTRL: Set parameters to 1000000000 maxbps, 50 window size
Dec  8 19:27:03 pptpd[649]: CTRL: Made a OUT CALL RPLY packet
Dec  8 19:27:03 ndm: kernel: Fast VPN ctrl: setup for src 176.59.8.66
Dec  8 19:27:03 pptpd[649]: CTRL: Starting call (launching pppd, opening GRE)
Dec  8 19:27:03 pptpd[649]: CTRL: I wrote 32 bytes to the client.
Dec  8 19:27:03 pptpd[651]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Dec  8 19:27:03 pptpd[649]: CTRL: Sent packet to client
Dec  8 19:27:03 pptpd[651]: CTRL (PPPD Launcher): local address = 192.168.1.1
Dec  8 19:27:03 pptpd[651]: CTRL (PPPD Launcher): remote address = 172.16.1.33
Dec  8 19:27:03 pptp[651]: Plugin pptp.so loaded.
Dec  8 19:27:03 pptp[651]: PPTP plugin version 0.8.3 compiled against pppd 2.4.4-4
Dec  8 19:27:03 pptp[651]: pppd 2.4.4-4 started by root, uid 0
Dec  8 19:27:03 pptp[651]: using channel 1
Dec  8 19:27:03 pptp[651]: Using interface vpn0
Dec  8 19:27:03 pptp[651]: Connect: vpn0 <--> pptp (176.59.8.66)
Dec  8 19:27:03 pptp[651]: sent [LCP ConfReq id=0x1 <mru 1350> <auth chap MS-v2> <magic 0x7b34133f> <pcomp> <accomp>]
Dec  8 19:27:04 pptp[651]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf09926e9> <pcomp> <accomp>]
Dec  8 19:27:04 pptp[651]: sent [LCP ConfRej id=0x1 <asyncmap 0x0>]
Dec  8 19:27:04 pptp[651]: rcvd [LCP ConfAck id=0x1 <mru 1350> <auth chap MS-v2> <magic 0x7b34133f> <pcomp> <accomp>]
Dec  8 19:27:04 pptp[651]: rcvd [LCP ConfReq id=0x2 <magic 0xf09926e9> <pcomp> <accomp>]
Dec  8 19:27:04 pptp[651]: sent [LCP ConfAck id=0x2 <magic 0xf09926e9> <pcomp> <accomp>]
Dec  8 19:27:04 pptp[651]: sent [LCP EchoReq id=0x0 magic=0x7b34133f]
Dec  8 19:27:04 pptp[651]: sent [CHAP Challenge id=0xe7 <72013475e251afa2806722785360b4b8>, name = "ndmpptpd"]
Dec  8 19:27:04 pptp[651]: rcvd [LCP EchoReq id=0x0 magic=0xf09926e9]
Dec  8 19:27:04 pptp[651]: sent [LCP EchoRep id=0x0 magic=0x7b34133f]
Dec  8 19:27:04 pptp[651]: rcvd [LCP EchoRep id=0x0 magic=0xf09926e9]
Dec  8 19:27:05 pptp[651]: rcvd [CHAP Response id=0xe7 <3b7f6341219487a19bdf42cf2eda8a8100000000000000004b1d4feac571a1e2a500ca7eeba0e6ae2b82e23c7b14d51e00>, name = "kuyvozi"]
Dec  8 19:27:05 pptp[651]: sent [CHAP Success id=0xe7 "S=AD30F8970D050D414150DDC01AE3E7CC2EB5E76F M=Access granted"]
Dec  8 19:27:05 pptp[651]: Script /var/run/vpnserver/auth_up started (pid 653)
Dec  8 19:27:05 pptp[651]: sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
Dec  8 19:27:05 pptp[651]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.1.1>]
Dec  8 19:27:05 pptp[651]: Script /var/run/vpnserver/auth_up finished (pid 653), status = 0x0
Dec  8 19:27:05 pptp[651]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Dec  8 19:27:05 pptp[651]: sent [IPCP ConfNak id=0x1 <addr 172.16.1.34> <ms-dns1 192.168.1.1> <ms-dns3 192.168.1.1>]
Dec  8 19:27:05 pptp[651]: rcvd [IPV6CP ConfReq id=0x1 <addr fe80::1d03:db49:d225:74ab>]
[W] Dec  8 19:27:05 pptp[651]: Unsupported protocol 'IPv6 Control Protovol' (0x8057) received
Dec  8 19:27:05 pptp[651]: sent [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 1d 03 db 49 d2 25 74 ab]
Dec  8 19:27:06 ndnproxy: max. requests 14 132 
Dec  8 19:27:06 ndnproxy: send udp request to: [3] 77.88.8.3#53
Dec  8 19:27:06 pptp[651]: rcvd [CCP ConfReq id=0x1]
Dec  8 19:27:06 pptp[651]: sent [CCP ConfAck id=0x1]
Dec  8 19:27:06 ndnproxy: max. requests 14 132 
Dec  8 19:27:06 ndnproxy: send udp request to: [3] 77.88.8.3#53
Dec  8 19:27:06 pptp[651]: rcvd [CCP ConfRej id=0x1 <mppe +H -M +S +L -D -C>]
[E] Dec  8 19:27:06 pptp[651]: MPPE required but cannot negotiate MPPE key length
Dec  8 19:27:06 pptp[651]: sent [CCP TermReq id=0x2"MPPE required but cannot negotiate MPPE key length"]
Dec  8 19:27:06 pptp[651]: rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.168.1.1>]
Dec  8 19:27:06 ndnproxy: max. requests 14 132 
Dec  8 19:27:06 ndnproxy: send udp request to: [3] 77.88.8.3#53
Dec  8 19:27:06 pptp[651]: rcvd [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 172.16.1.34> <ms-dns1 192.168.1.1> <ms-dns3 192.168.1.1>]
Dec  8 19:27:06 pptp[651]: sent [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 172.16.1.34> <ms-dns1 192.168.1.1> <ms-dns3 192.168.1.1>]
Dec  8 19:27:06 pptp[651]: local  IP address 192.168.1.1
Dec  8 19:27:06 pptp[651]: remote IP address 172.16.1.34
Dec  8 19:27:06 pptp[651]: Script /var/run/vpnserver/client_up started (pid 656)
Dec  8 19:27:06 ndnproxy: max. requests 14 132 
Dec  8 19:27:06 ndnproxy: send udp request to: [3] 77.88.8.3#53
Dec  8 19:27:06 pptp[651]: Script /var/run/vpnserver/client_up finished (pid 656), status = 0x0
Dec  8 19:27:06 pptp[651]: rcvd [CCP TermAck id=0x2]
Dec  8 19:27:07 ndnproxy: max. requests 14 132 
Dec  8 19:27:07 ndnproxy: send udp request to: [3] 77.88.8.3#53
Dec  8 19:27:08 pptp[651]: rcvd [CCP ConfReq id=0x1]
Dec  8 19:27:08 pptp[651]: sent [CCP TermAck id=0x1]
Dec  8 19:27:08 pptp[651]: rcvd [CCP TermReq id=0x2"No compression negotiated"]
Dec  8 19:27:08 pptp[651]: sent [CCP TermAck id=0x2]

 

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0

Лучше снимите dump-ы трафика с отключенным шифрованием PPTP на WAN и на Home через Захват пакетов при пинге из сети LEDE, с роутера LEDE, с Ультры, и из сети Ультры. Тогда возможно что-то подскажем.

Share this post


Link to post
Share on other sites
  • 0
В 02.11.2017 в 00:23, Андрэ Палыч сказал:

Спасибо  большое  за  внимание!  вот  снял дампы  с внешного и внутренного интерфесов и пинговал  по очереди в обе стороны (и из Ультры и со стороны  Lede ).  Как  выяснилось  со стороны LEDE  доступна  только сама Ультра,  а  пинги на  хосты  позади неё не проходят)

вот  эти пакеты  странные:

102    9.553020    10.189.152.77    88.221.132.41    ICMP    82    Destination unreachable (Host unreachable)

107    9.553420    10.189.152.77    104.122.248.105    ICMP    82    Destination unreachable (Host unreachable)

10.189.152.77 это серый статический адрес выданный  провайдером Ультре. Он из интернета не виден (только  во внутренней сети провайдера).  Я пинговал с хоста 192.168.1.52 по адресу 192.168.3.1. а  они отправились на  88.х.х.х и 104.х.х.х??? непонятно...

 

вот  маршруты на LEDE

root@kuyvozi:~# route  
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.104.249.241  0.0.0.0         UG    5      0        0 wwan0
default         192.168.1.1     0.0.0.0         UG    10     0        0 pptp-vpn
10.104.249.240  *               255.255.255.252 U     5      0        0 wwan0
10.104.249.241  *               255.255.255.255 UH    5      0        0 wwan0
X.X.X.28   10.104.249.241  255.255.255.255 UGH   5      0        0 wwan0
192.168.1.1     *               255.255.255.255 UH    0      0        0 pptp-vpn    этот маршрут поднимается автоматически,  почему он до узла а не до сети?
192.168.3.0     *               255.255.255.0   U     0      0        0 br-lan

 

 

 

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0
9 часов назад, denisy сказал:

вот  маршруты на LEDE

root@kuyvozi:~# route  
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.104.249.241  0.0.0.0         UG    5      0        0 wwan0
default         192.168.1.1     0.0.0.0         UG    10     0        0 pptp-vpn
10.104.249.240  *               255.255.255.252 U     5      0        0 wwan0
10.104.249.241  *               255.255.255.255 UH    5      0        0 wwan0
188.134.72.28   10.104.249.241  255.255.255.255 UGH   5      0        0 wwan0
192.168.1.1     *               255.255.255.255 UH    0      0        0 pptp-vpn    этот маршрут поднимается автоматически,  почему он до узла а не до сети?
192.168.3.0     *               255.255.255.0   U     0      0        0 br-lan

Для сравнения вам клиент VPN, даннвй маршрут который красный - ДОЛЖЕН БЫТЬ, почему ниже

~# ip ro
default via хх.хх.хх.52 dev ppp0  scope link 
...
хх.хх.хх.52 dev ppp0  scope link 
IP_белый_VPN-Server dev ppp0  scope link src хх.хх.хх.52 
192.168.1.0/24 dev ppp1  scope link 
192.168.1.1 dev ppp1  proto kernel  scope link  src 192.168.10.9 
192.168.130.0/24 dev br0  proto kernel  scope link  src 192.168.130.99 
~# 

192.168.1.1 - удаленный роутер, 192.168.10.9 - VPN туннель, ppp0 - канал интернета
192.168.1.0/24 стат маршрут добавлен
192.168.1.1 dev ppp1 .... - маршурт до узла должен быть, поднялся же VPN туннуль (PPP точка точка) через сетевой интерфейс 192.168.10.9

На VPN клиенте 192.168.130.99
~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=24.393 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=10.790 ms
64 bytes from 192.168.1.1: seq=2 ttl=64 time=22.617 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 10.790/19.266/24.393 ms
~# ping 192.168.1.207
PING 192.168.1.207 (192.168.1.207): 56 data bytes
64 bytes from 192.168.1.207: seq=0 ttl=63 time=10.135 ms
64 bytes from 192.168.1.207: seq=1 ttl=63 time=10.568 ms
^C
--- 192.168.1.207 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 10.135/10.351/10.568 ms
~# 

~# cat /tmp/pptpd_client/options.vpn
defaultroute
...
nodeflate
...
:~# 

Для сравнения на VPN-Клиенте Keenetic

(config)> show ip route 
================================================================================
Destination          Gateway           Interface                         Metric 
================================================================================
0.0.0.0/0            0.0.0.0           PPPoE0                            0      
...
IP_белый_VPN-Сервер  0.0.0.0           PPPoE0                            0      
192.168.1.0/24       192.168.10.9      PPTP0                             0      
192.168.1.1/32       0.0.0.0           PPTP0                             0      
192.168.130.0/24     0.0.0.0           Home                              0      
...
(config)> 

или

/ # ip ro
default dev ppp0  scope link 
...
IP_белый_VPN-Сервер dev ppp0  scope link 
192.168.1.0/24 dev ppp1  scope link 
192.168.1.1 dev ppp1  proto kernel  scope link src 192.168.10.9 
192.168.130.0/24 dev br0  proto kernel  scope link  src 192.168.130.1 
...
/ # 

стат маршрут 192.168.1.0/24 dev ppp1 - добавлен
маршрут 192.168.1.1 dev ppp1 - так же есть в наличие и должен быть так как есть сетевой интерфейс

ppp1      Link encap:Point-to-Point Protocol  
          inet addr:192.168.10.9  P-t-P:192.168.1.1  Mask:255.255.255.255

 

Edited by vasek00

Share this post


Link to post
Share on other sites
  • 0
2 часа назад, vasek00 сказал:

Спасибо!  Вот маршруты с LEDE .  очень  похоже на  ваш  пример .

root@kuyvozi:~# ip ro
root@kuyvozi:~# ip ro
default via 10.104.249.241 dev wwan0  src 10.104.249.242  metric 5  
default via 192.168.1.1 dev pptp-vpn  metric 10  
10.104.249.240/30 dev wwan0  metric 5  
10.104.249.241 dev wwan0  src 10.104.249.242  metric 5  
XXX.XXX.XX.28 via 10.104.249.241 dev wwan0  metric 5  
192.168.1.1 dev pptp-vpn  src 172.16.1.34  
192.168.3.0/24 dev br-lan  src 192.168.3.1


по  дампам  трафика с WAN интерфейса Ультры  я  вижу  приходящие ICMP пакеты  при пинге по адресу 192.168.1.1 (внутренняя  сеть Ультры)  однако  когда я пингую хост в локальной сети Ультры 192.168.1.52 (Все пинги из терминала LEDE), то  на WAN Ультры похоже вообще ничего не приходит....  снять дамп с wwan0  пока не могу.

В настройках LEDE похоже есть какой-то затык  с маршрутизацией по адресам  внутненней сети Ультры, однако мне этот функционал и не нужен.  Мне нужен доступ к устройствам во внутренней сети LEDE  из внутренней сети Ультры,  а он  присутствует только в терминале  ультры...  Вот  что имеется на Ультре

(config)> show ip route
================================================================================
Destination          Gateway           Interface                         Metric  
================================================================================
0.0.0.0/0            10.189.152.1      ISP                               0       
10.1.30.0/24         0.0.0.0           Guest                             0       
10.189.152.0/24      0.0.0.0           ISP                               0       
172.16.1.34/32       0.0.0.0           VPN                               0       
192.168.1.0/24       0.0.0.0           Home                              0       
192.168.3.0/24       172.16.1.34       VPN                               0       
(config)>


vasek00 покажите  пожалуйста  маршруты  на вашем pptp сервере?

 

2 часа назад, vasek00 сказал:

 

 

 

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0
19 минут назад, denisy сказал:

по  дампам  трафика с WAN интерфейса Ультры  я  вижу  приходящие ICMP пакеты  при пинге по адресу 192.168.1.1 (внутренняя  сеть Ультры)  однако  когда я пингую хост в локальной сети Ультры 192.168.1.52 (Все пинги из терминала LEDE), то  на WAN Ультры похоже вообще ничего не приходит....  снять дамп с wwan0  пока не могу (не знаю как  в терминале  сделать это).

Да в принципе у всех так должно быть.

Все что вы ping с роутеров это одно, так как по УМОЛЧАНИЮ на них всех есть маршрут до соседнего роутера из-за поднятого  VPN (PPP), но нет маршрутов до лок.сети, вам нужно прописать маршруты на LEDE

route add -net 192.168.1.0 netmask 255.255.255.0 gw 172.16.1.34

или

ip ro add 192.168.1.0/24 via 172.16.1.34 dev pptp-vpn

на сервере VPN (Ultra) для клиента выделить IP_VPN 172.16.1.34, чтоб при подключении данным клиентом всегда получать данный IP.

Второе откуда два default смотрите в настройках LEDE настройка интерфейса (да еще и с метрикой, чем меньше тем выше приоритет). Самое главное для чего таблица маршрутов - если адресата нет в таблице маршрутов, то отсылать пакеты по маршруту default. Смотря на вашу таблицу при адресате 192.168.1.52 данного направления в виде 192.168.1.0/24 в текущей нет => пакет будут направлены в default который с метрикой 5.

Третье на стороне Ultra так же прописать маршрут, про него говорили в постах выше "ip route ......".

Проверил схему, работает

Сеть1 ------ KII(VPNServ) --- Инет ---- (VPNClient)роутер2 ------ Сеть2

 

 

Share this post


Link to post
Share on other sites
  • 0

Вах!  Заработало после  добавления это маршрута (ip ro add 192.168.1.0/24 via 172.16.1.34 dev pptp-vpn) и изменения метрики второго маршрута по умолчанию на LEDE.  Теперь маршруты по умолчанию  на LEDE  вот такие

default via 10.104.249.241 dev wwan0  src 10.104.249.242  metric 20 
default via 192.168.1.1 dev pptp-vpn  metric 10

все заработало!  Спасибо за помощь!

Правда  теперь весь трафик  пойдет через VPN канал,  что не входило  в мои планы, но  с этим я  как нибудь позднее разберусь. Главное  теперь есть полный доступ! Спасибо большое!

 

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0
1 час назад, denisy сказал:

изменения метрики второго маршрута по умолчанию на LEDE.  Теперь маршруты по умолчанию  на LEDE  вот такие

default via 10.104.249.241 dev wwan0  src 10.104.249.242  metric 20 
default via 192.168.1.1 dev pptp-vpn  metric 10

Правда  теперь весь трафик  пойдет через VPN канал,  что не входило  в мои планы, но  с этим я  как нибудь позднее разберусь. Главное  теперь есть полный доступ! Спасибо большое!

Убирайте default с данного VPN канала (см. настройки на данном "pptp-vpn" в LEDE)

Share this post


Link to post
Share on other sites
  • 0
2 часа назад, vasek00 сказал:

Убирайте default с данного VPN канала (см. настройки на данном "pptp-vpn" в LEDE)

попробовал  убрать, но тогда  доступ  из локалки Ультры опять пропадает. Пришлось вернуть.  Чудеса  какие-то.

Share this post


Link to post
Share on other sites
  • 0
33 минуты назад, denisy сказал:

попробовал  убрать, но тогда  доступ  из локалки Ультры опять пропадает. Пришлось вернуть.  Чудеса  какие-то.

Что-то вы не то убираете?

root@kuyvozi:~# ip ro
default via 10.104.249.241 dev wwan0  src 10.104.249.242  metric 5  
default via 192.168.1.1 dev pptp-vpn  metric 10  
10.104.249.240/30 dev wwan0  metric 5  
10.104.249.241 dev wwan0  src 10.104.249.242  metric 5  
XXX.XXX.XX.28 via 10.104.249.241 dev wwan0  metric 5  
192.168.1.1 dev pptp-vpn  src 172.16.1.34  
192.168.3.0/24 dev br-lan  src 192.168.3.1

Нужно

root@kuyvozi:~# ip ro
default via 10.104.249.241 dev wwan0 src 10.104.249.242  metric 5  
10.104.249.240/30 dev wwan0  metric 5  
10.104.249.241 dev wwan0  src 10.104.249.242  metric 5  
XXX.XXX.XX.28 via 10.104.249.241 dev wwan0  metric 5  
192.168.1.1 dev pptp-vpn src 172.16.1.34  
192.168.1.0/24 dev pptp-vpn src 172.16.1.34  
192.168.3.0/24 dev br-lan src 192.168.3.1

 

Share this post


Link to post
Share on other sites
  • 0
4 часа назад, vasek00 сказал:

Что-то вы не то убираете?

да  вроде все то,  вот в  терминале  сохранилось  как оно было:

 

root@kuyvozi:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default        10.104.249.241  0.0.0.0         UG    20     0        0 wwan0
10.104.249.240  *               255.255.255.252 U     20     0        0 wwan0
10.104.249.241  *               255.255.255.255 UH    20     0        0 wwan0
XXX.XXX.XX.28   10.104.249.241  255.255.255.255 UGH   20     0        0 wwan0
192.168.1.1     *               255.255.255.255 UH    0      0        0 pptp-vpn
192.168.3.0     *               255.255.255.0   U     0      0        0 br-lan

 

Edited by denisy

Share this post


Link to post
Share on other sites
  • 0
11 час назад, denisy сказал:

да  вроде все то,  вот в  терминале  сохранилось  как оно было:
192.168.1.1     *               255.255.255.255 UH    0      0        0 pptp-vpn

Ну как же, как говориться найдите разницу

192.168.1.1 dev pptp-vpn  src 172.16.1.34
192.168.1.0/24 dev pptp-vpn src 172.16.1.34 
Edited by vasek00

Share this post


Link to post
Share on other sites
  • 0
1 минуту назад, vasek00 сказал:

Ну как же, как говориться найдите разницу


192.168.1.1 dev pptp-vpn  src 172.16.1.34
192.168.1.0/24 dev pptp-vpn src 172.16.1.34 

Спасибо,  в  самом деле  почему-то этот маршрут

192.168.1.0/24 dev pptp-vpn src 172.16.1.34 

не поднимается автоматически если он не "по умолчанию" в настройках pptp клиента LEDE. Пропишу  руками.  Еще раз спасибо большое помощь! 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...