denisy
-
Posts
13 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by denisy
-
-
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. Пропишу руками. Еще раз спасибо большое помощь!
-
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
-
2 часа назад, vasek00 сказал:
Убирайте default с данного VPN канала (см. настройки на данном "pptp-vpn" в LEDE)
попробовал убрать, но тогда доступ из локалки Ультры опять пропадает. Пришлось вернуть. Чудеса какие-то.
-
Вах! Заработало после добавления это маршрута (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 канал, что не входило в мои планы, но с этим я как нибудь позднее разберусь. Главное теперь есть полный доступ! Спасибо большое!
-
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 сказал: -
В 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
-
В 02.11.2017 в 00:23, Андрэ Палыч сказал:
У меня точно такая же проблема на Ультре (pptp сервер - дома, провайдер Interzet, статический адрес есть, но он не известен кинетику, так как WAN у провайдера организован по серой схеме со статическим адресом типа 10.189.х.х). На другом конце стоит LEDE 17.01 Asus wl520gp v2, pptp клиент). Проблему подробнее описал тут
-
Нарыл еще ошибку с 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] -
В логах вроде бы ничего особенного кроме ошибки шифрования, но соединение установлено и пинг из телнета на ультре есть...
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 -
судя по всему инструкция ip nat vpn эквивалентна галке в веб интерфейсе Транслировать адреса клиентов (NAT)
я пробовал и так и эдак но результат один
- из локальной сети Ультры пинги не проходят
-
Только что, KorDen сказал:
А на удаленном роутере маршрут в локальную сеть ультры через туннель есть-то? Или включить "ip nat vpn" на ультре..
да, они автоматически там поднимаются и проблем с доступом к локальной сети Ультры не наблюдается. пробую ip nat vpn ... спасибо за ответ... отпишусь
-
Здравствуйте,
Никак не могу побороть похожую проблему. Имеется 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.
Спасибо
- из локальной сети Ультры пинги не проходят
При нагрузке Wi-Fi 5 ггц постоянно отваливается
in 2.10
Posted
Ultra 2.10 та же картина, придется шить эксперементальную версию 2.11. на ней вроде вопрос был решен.
Отправлено с моего ONEPLUS A3003 через Tapatalk