Перейти к содержанию

pppd и pptpd Entware на Keenetic

dexter
 Поделиться

Рекомендуемые сообщения

dexter Старожил

dexter

Опубликовано
Опубликовано

Соединение до удаленного сервера поднимается, маршрут прописался через 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

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Соединение до удаленного сервера поднимается, маршрут прописался через 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 обмена клиента и сервера увидеть.

dexter Старожил

dexter

Опубликовано
  • Автор
Опубликовано

А так нельзя

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

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

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
А так нельзя

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

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

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

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

dexter Старожил

dexter

Опубликовано
  • Автор
Опубликовано

Что выяснил.

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

ip route add 31.129.192.0/24 via 192.168.3.254

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

Le ecureuil Старожил

Le ecureuil

Опубликовано
Опубликовано
Что выяснил.

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

ip route add 31.129.192.0/24 via 192.168.3.254

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

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

dexter Старожил

dexter

Опубликовано
  • Автор
Опубликовано

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

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

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

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

dexter Старожил

dexter

Опубликовано
  • Автор
Опубликовано

Запустил 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 - не работают.

  • 1 месяц спустя...
dexter Старожил

dexter

Опубликовано
  • Автор
Опубликовано

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

Настроил 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.

  • 8 месяцев спустя...
Алексей Сторин Новичок

Алексей Сторин

Опубликовано
Опубликовано
5 часов назад, zyxmon сказал:

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

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

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
 Поделиться
Перейти к списку тем

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю