LINUX.ORG.RU
ФорумAdmin

VPN через pptpd

 


0

1

Здравствуй, уважаемый all.

Есть удалённый сервер по адресу x.x.x.x(eth1 смотрит в интернет), мы с друзьями хотим поверх него организовать «локалку». Для чего был поставлен pptpd и выполнены следующие настройки: /etc/pptpd.conf

#ppp /usr/sbin/pppd
option /etc/ppp/options.pptpd
#debug
#stimeout 10
#noipparam
logwtmp
#vrf test
#bcrelay eth1
#delegate
connections 20
localip 192.168.100.1
remoteip 192.168.100.101-120
/etc/ppp/options.pptpd
name pptpd

refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128


#-chap
#-chapms
#+chapms-v2
#mppe-40	# enable either 40-bit or 128-bit, not both
#mppe-128
#mppe-stateless

ms-dns 8.8.8.8
ms-dns 8.8.4.4
ms-wins 192.168.100.1
proxyarp
#nodefaultroute
#debug
#dump
lock
nobsdcomp 
novj
novjccomp
nologfd
iptables-save
# Generated by iptables-save v1.4.7 on Tue Jan  5 16:56:01 2016
*nat
:PREROUTING ACCEPT [3081:315776]
:POSTROUTING ACCEPT [204:12240]
:OUTPUT ACCEPT [589:35071]
-A POSTROUTING -s 192.168.100.0/24 -o eth1 -j MASQUERADE 
-A POSTROUTING -o eth1 -j MASQUERADE 
-A POSTROUTING -o ppp+ -j MASQUERADE 
COMMIT
# Completed on Tue Jan  5 16:56:01 2016
# Generated by iptables-save v1.4.7 on Tue Jan  5 16:56:01 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [19167:17355297]
-A INPUT -p tcp -m state --state NEW -m tcp --dport 1723 -j ACCEPT 
-A INPUT -p gre -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -s 127.0.0.1/32 -p tcp -m state --state NEW -m tcp -m multiport --dports 11222 -j ACCEPT 
-A INPUT -s z.z.z.z/32 -p tcp -m state --state NEW -m tcp -m multiport --dports 20,21,22 -j ACCEPT 
-A INPUT -s zz.zz.zz.zz/32 -p tcp -m state --state NEW -m tcp -m multiport --dports 3306,11222 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 80,1080,8999,9099,10011 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 9000:9010 -j ACCEPT 
-A INPUT -s 192.168.100.0/24 -i ppp+ -j ACCEPT 
-A INPUT -j DROP 
-A FORWARD -d 192.168.100.0/24 -i eth1 -j ACCEPT 
-A FORWARD -s 192.168.100.0/24 -o eth1 -j ACCEPT 
-A FORWARD -i ppp+ -j ACCEPT 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 
COMMIT
# Completed on Tue Jan  5 16:56:01 2016
Результат - виндовые-vpn-клиенты прекрасно коннектятся, видят 192.168.100.1 и внешку(на сервере появляются ppp0, ppp1, ...), но друг друга не пингуют; vpn-клиенты находятся в разных интернетах.

Подскажите что я не учёл ? *при отключённом iptables ситуация не меняется кардинальным образом ( ну точнее за счёт отсутствия форварда у клиентов отсутствует интернет ). пробовал прописывать маршрут на вин-машинах -

route add 192.168.100.0 mask 255.255.255.0 192.168.100.1
- также не помогает. net.ipv4.ip_forward включён.

p.s. ip-адреса выдаются статически через /etc/ppp/chap-secrets

Заранее огромное спасибо!



Последнее исправление: rumos (всего исправлений: 3)

но друг друга не пингуют

по каким адресам пингуем и что говорит tcpdump на том же сервере?

-A POSTROUTING -o ppp+ -j MASQUERADE

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

anc ★★★★★
()

Надо рыться в доках pptpd. Как возможный вариант решения ethernet bridge. Другой вариант через iptables -t nat. Но сначала проверить доки, т.к. вполне возможно это фича (как и в openvpn).

gh0stwizard ★★★★★
()

Фиг знает.
Попробуй убрать localip и remoteip, включить delegate и раздавать айпишники из chap-secrets. Для чистоты эксперимента iptables выгрузи, а форвардинг, конечно, включи.
Ну и убедись лишний раз, что видеть друг друга вендам не мешает их же фаерволл.

thesis ★★★★★
()
Ответ на: комментарий от anc

хотелось за 5 минут

вот и выбрал pptp ;) но уже начинаю думать об openvpn, хотя всё же добить работу именно с pptp охота.

rumos
() автор топика
Ответ на: комментарий от thesis

1)iptables правила drop/reject убрал, всё прочее оставил. 2)включил delegate, убрал localip, remoteip, получил на вин-машине ошибку 720. вероятно там была попытка раздать внешний айпишник сервера вместо айпишников chap-secrets. 3)кстати ip-адреса от chap-secrets нормально назначаются ( в вариации без delegate, с proxyarp но без bcrelay ).

меня искренне смущает маска /32 и отстутствие шлюза в получаемом соединении - думаю проблема именно в этом.

rumos
() автор топика
Ответ на: комментарий от anc

допустим два клиента - получили адреса при коннекте 192.168.100.102 и 192.168.100.105; шлюз в конфиге 192.168.100.1, но он не раздаётся в свойства соединения ( и в свойствах соединения маска 255.255.255.255 ). эти клиенты - физически два разных провайдера, но два ноута стоящих рядом. на одном вин-7ка, на другом вин-8ка;

при пинге с .105 на .102 tcpdump показывает только ехо-реквест; при пинге с .105 на .1 пинг идёт и показывается как реквест так и реплай.

-- попытка пингануть .105 или .102 с сервера также оканчивается ничем ( в дампе показывается реквест ).

трэйсроут сразу же начинает показывать ***. --

я полагаю что как-то надо серверу объяснить что по любым вопросам типа 192.168.100.0/24 надо ходить на ppp+ интерфейсы и у них что-то спрашивать.. только не знаю как :)

rumos
() автор топика
Ответ на: хотелось за 5 минут от rumos

Не правильный выбор:
Это openvpn - «5 минут»
А pptpd - «100500 минут гемороя» :)

anc ★★★★★
()
Ответ на: комментарий от rumos

Вот выше уже написали «Ну и убедись лишний раз, что видеть друг друга вендам не мешает их же фаерволл.»
Проверьте не на вин машинах.

anc ★★★★★
()
-A FORWARD -i ppp+ -j ACCEPT 

забыл на выход разрешить. добавь

-A FORWARD -o ppp+ -j ACCEPT 

и вот это

-A FORWARD -d 192.168.100.0/24 -i eth1 -j ACCEPT 
-A FORWARD -s 192.168.100.0/24 -o eth1 -j ACCEPT 
ни к чему. адреса 192.168.100.0/24 у тебя в ppp+, а не на инетном интерфейсе.

P.S. настройка pptpd реально занимает 5 мин, а вот iptables надо дольше курить независимо от pptp/openvpn

Toshik
()
Ответ на: комментарий от Toshik

Народ себе экзитпоинт поднимает, а ты с дурацкими советами :) Читай внимательнее и см. конфиги ТС там дэфроут и маскарад.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.