Jump to content
Sign in to follow this  
dexter

pppd и pptpd Entware на Keenetic

Recommended Posts

Соединение до удаленного сервера поднимается, маршрут прописался через ip route.

Но удаленный хост(он же сервер/шлюз) в тунеле не пингуется. Прописал правила фаервола, которые на V1 работали.

# Разрешаем внутрисетевой обмен
iptables -I INPUT -i lo -j ACCEPT

# Открываем доступ к vpn снаружи
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

# Правила для 47 порта
iptables -A INPUT -p 47 -j ACCEPT
iptables -A OUTPUT -p 47 -j ACCEPT

# PPTP internet
iptables -I INPUT -i ppp+ -j ACCEPT
iptables -I FORWARD -i ppp+ -j ACCEPT
iptables -I FORWARD -o ppp+ -j ACCEPT
iptables -I OUTPUT -o ppp+ -j ACCEPT

# pptp client-to-client
iptables -I FORWARD -i ppp+ -o ppp+ -j ACCEPT
 

Тут ещё правила относящиеся к серверной части.

Есть мысли, чего ещё не так. Пинговал с самого сервера.

Почему поднимаю не из прошивки?

Этот коннект на удаленный сервер вызывается скриптом ip-up pptpd.

В архиве полностью конфа сервера и клиентского соединения. pptpd сервер пока не проверял, начал с клиента.

Повторюсь, эта связка работоспособна была на Entware + Keenetic V1 и сейчас работает на debian.

ppp.rar

Share this post


Link to post
Share on other sites
Соединение до удаленного сервера поднимается, маршрут прописался через ip route.

Но удаленный хост(он же сервер/шлюз) в тунеле не пингуется. Прописал правила фаервола, которые на V1 работали.

# Разрешаем внутрисетевой обмен
iptables -I INPUT -i lo -j ACCEPT

# Открываем доступ к vpn снаружи
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

# Правила для 47 порта
iptables -A INPUT -p 47 -j ACCEPT
iptables -A OUTPUT -p 47 -j ACCEPT

# PPTP internet
iptables -I INPUT -i ppp+ -j ACCEPT
iptables -I FORWARD -i ppp+ -j ACCEPT
iptables -I FORWARD -o ppp+ -j ACCEPT
iptables -I OUTPUT -o ppp+ -j ACCEPT

# pptp client-to-client
iptables -I FORWARD -i ppp+ -o ppp+ -j ACCEPT

Тут ещё правила относящиеся к серверной части.

Есть мысли, чего ещё не так. Пинговал с самого сервера.

Почему поднимаю не из прошивки?

Этот коннект на удаленный сервер вызывается скриптом ip-up pptpd.

В архиве полностью конфа сервера и клиентского соединения. pptpd сервер пока не проверял, начал с клиента.

Повторюсь, эта связка работоспособна была на Entware + Keenetic V1 и сейчас работает на debian.

# Открываем доступ к vpn снаружи
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT

Для PPTP этого недостаточно, еще нужно разрешить GRE:

iptables -A INPUT -p gre -j ACCEPT

Само соединение-то поднимается? Неплохо бы дамп в wireshark обмена клиента и сервера увидеть.

Share this post


Link to post
Share on other sites

А так нельзя

# Правила для 47 порта
iptables -A INPUT -p 47 -j ACCEPT
iptables -A OUTPUT -p 47 -j ACCEPT

В данном случае клиент(на Ultra 2) не пингует сервер. Хотя туннель поднялся и в ifconfig видны его параметры.

Share this post


Link to post
Share on other sites
А так нельзя

# Правила для 47 порта
iptables -A INPUT -p 47 -j ACCEPT
iptables -A OUTPUT -p 47 -j ACCEPT

В данном случае клиент(на Ultra 2) не пингует сервер. Хотя туннель поднялся и в ifconfig видны его параметры.

Можно и так, только это не порт 47, а номер IP-протокола для GRE.

Если туннель поднялся, значит GRE работает нормально - очередь разбираться с нетфильтром и роутингом.

Share this post


Link to post
Share on other sites

Что выяснил.

Доступ до 192.168.3.254 пропадает сразу после задачи маршрута

ip route add 31.129.192.0/24 via 192.168.3.254

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

Share this post


Link to post
Share on other sites
Что выяснил.

Доступ до 192.168.3.254 пропадает сразу после задачи маршрута

ip route add 31.129.192.0/24 via 192.168.3.254

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

Маршрут тоже можно прописать через морду.

Share this post


Link to post
Share on other sites

Мне это не удобно.

Ещё раз напишу для чего это нужно.

Поднимается pptp сервер на кинетике дома. Когда подключается определенный клиент к домашнему серверу, в скрипте ip-up срабатывает впн дозвон до удаленного сервера. Запускаем "call test" и прописываем маршрут на удаленную подсеть которая находится за тем pptp сервером.

Просто не могу понять чего не хватает(по видимому в фаерволе) для корректной работы данной связки.

Share this post


Link to post
Share on other sites

Запустил tcpdump на интерфейсе ppp0 и включил ping 192.168.3.254 удаленный хост в туннеле.

До добавления маршрута

 # tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:55:57.574508 IP 192.168.3.7 > 192.168.3.254: ICMP echo request, id 29961, seq 11, length 64
17:55:57.577276 IP 192.168.3.254 > 192.168.3.7: ICMP echo reply, id 29961, seq 11, length 64

После добавления мвршрута молниеносно и в огромных количествах начинает сыпать такое

17:58:57.321233 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16170, length 1376: compressed PPP data
17:58:57.321388 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16171, length 1376: compressed PPP data
17:58:57.321544 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16172, length 1376: compressed PPP data
17:58:57.321699 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16173, length 1376: compressed PPP data
17:58:57.321855 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16174, length 1376: compressed PPP data
17:58:57.322010 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16175, length 1376: compressed PPP data
17:58:57.322165 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16176, length 1376: compressed PPP data
17:58:57.322365 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16177, length 1376: compressed PPP data
17:58:57.322627 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16178, length 1376: compressed PPP data
17:58:57.322876 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16179, length 1376: compressed PPP data
17:58:57.323121 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16180, length 1376: compressed PPP data
17:58:57.323373 IP 192.168.105.5 > 31.129.192.22: GREv1, call 16896, seq 16181, length 1376: compressed PPP data

Поднял pptp сервер из entware-ng. Все заработало, коннект устанавливается, но не пингуется ни сервер с клиента, ни клиент с сервера. Чую дело в фаерволе, но не знаю какие правила прописать. Те, что работали на V1 - не работают.

Share this post


Link to post
Share on other sites

Что-то я совсем ничего не понимаю :?

Настроил PPPTP сервер из пакетов Entware. Соединение устанавливается, кинетик я пингую и на вэб интерфейс попадаю по IP PPTP сервера.

А теперь самое интересное.

Включаем снифер на машине в которую воткнут кинетик и видим такую картину

22:00:24.849215 IP 192.168.105.5 > www.yandex.ru: ICMP echo request, id 512, seq 37121, length 40
22:00:24.853437 IP www.yandex.ru > 192.168.105.5: ICMP echo reply, id 512, seq 37121, length 40
22:00:25.849232 IP 192.168.105.5 > www.yandex.ru: ICMP echo request, id 512, seq 37377, length 40
22:00:25.853646 IP www.yandex.ru > 192.168.105.5: ICMP echo reply, id 512, seq 37377, length 40
22:00:26.856038 IP 192.168.105.5 > www.yandex.ru: ICMP echo request, id 512, seq 37633, length 40
22:00:26.860895 IP www.yandex.ru > 192.168.105.5: ICMP echo reply, id 512, seq 37633, length 40

192.168.105.5 IP на WAN порту кинетика, яндекс пингую с компа за натом. Все отлично.

Устанавливаю PPTP соединение и что же я вижу в снифере

22:00:26.856038 IP 192.168.105.5 > www.yandex.ru: ICMP echo request, id 512, seq 37633, length 40
22:00:26.860895 IP www.yandex.ru > 192.168.105.5: ICMP echo reply, id 512, seq 37633, length 40
22:00:27.884215 IP 192.168.40.20 > www.yandex.ru: ICMP echo request, id 1280, seq 256, length 40
22:00:33.017453 IP 192.168.40.20 > www.yandex.ru: ICMP echo request, id 1280, seq 512, length 40
22:00:38.508165 IP 192.168.40.20 > www.yandex.ru: ICMP echo request, id 1280, seq 768, length 40
22:00:44.004182 IP 192.168.40.20 > www.yandex.ru: ICMP echo request, id 1280, seq 1024, length 40

Появляется IP 192.168.40.20. Это IP выданный сервером PPTP клиенту. Т.е. форвард работает, а masquerade нет.

Прописал 4 правила iptables.

iptables -A INPUT -i ppp0 -j ACCEPT
iptables -A FORWARD -i ppp0 -j ACCEPT
iptables -A FORWARD -o ppp0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth2 -s 192.168.40.0/24 -j MASQUERADE

Уже не знаю чего ещё придумать. Device Ultra 2.

Share this post


Link to post
Share on other sites

Я не могу понять почему не работает masquerade? Где ошибка?

Share this post


Link to post
Share on other sites
Я не могу понять почему не работает masquerade? Где ошибка?
Смотрите по счетчикам пакетов на правилах.

Share this post


Link to post
Share on other sites
5 часов назад, zyxmon сказал:

Это тема не про pppd и pptpd, а про то, что не пингуется удаленный сервер. И у Вас не пингуется?

После добавления маршрутов и правки iptables - пингуется. Но есть проблемы с настройкой и работой впринципе.

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
Reply to this topic...

×   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.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...