LINUX.ORG.RU
ФорумAdmin

Проблемы с VPN PPTPD

 , , , ,


0

1

Суть такова: Есть роутер, за ним дома стоит сервер (CentOS 6.5) с одним только интерфейсом eth0 и привязанным IP: 192.168.1.20, он же на роутере как DMZ, то есть проброс и настройка портов не нужны. И есть внешний IP который динамический и привязывается к домену по переподключению.

Проблема следующая, подключается клиент на windows, подключение проходит без проблем и ошибок, я вижу что он есть как ppp0, ppp1 и т.д. я могу до него достучатся с любого другого устройства со своей сети.Пинг и трассера до любого сайта доходят в идеале. Но все к чему может получить доступ клиент это гугл, и ютюб. Оба работают идеально. Все остальное либо не открывается вобще, либо открывается со скоростью прошлого века 1-2кб/с.

Вот содержания файлов.

[root@localhost ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted
[root@localhost ~]# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Fri Aug 15 20:30:32 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [67:7635]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth+ -j ACCEPT
-A INPUT -i ippp+ -j ACCEPT
-A INPUT -i isdn+ -j ACCEPT
-A INPUT -i ppp+ -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A INPUT -i wlan+ -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -i eth0 -p gre -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1723 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth+ -j ACCEPT
-A FORWARD -i ippp+ -j ACCEPT
-A FORWARD -i isdn+ -j ACCEPT
-A FORWARD -i ppp+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i wlan+ -j ACCEPT
-A FORWARD -o eth+ -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Fri Aug 15 20:30:32 2014
# Generated by iptables-save v1.4.7 on Fri Aug 15 20:30:32 2014
*nat
:PREROUTING ACCEPT [140:25532]
:POSTROUTING ACCEPT [1:334]
:OUTPUT ACCEPT [2:208]
-A POSTROUTING -o eth+ -j MASQUERADE
COMMIT
# Completed on Fri Aug 15 20:30:32 2014
[root@localhost ~]# cat /etc/sysctl.conf
# Controls IP packet forwarding
net.ipv4.ip_forward = 1

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

# Controls the default maxmimum size of a mesage queue
kernel.msgmnb = 65536

# Controls the maximum size of a message, in bytes
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 4294967295

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 268435456


 [root@localhost ~]# cat  /etc/ppp/options.pptpd
# Authentication

name pptpd

# BSD licensed ppp-2.4.2 upstream with MPPE only, kernel module ppp_mppe.o
# {{{
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
require-mppe-128
# }}}

proxyarp
lock
nobsdcomp
novj
novjccomp
nologfd

ms-dns 192.168.1.20
ms-dns 192.168.1.1

Присоздании подключения запускается скрипт:

[root@localhost ~]# cat  /etc/ppp/ip-up.local
#!/bin/sh
PPTP_IF=$1                # Имя виртуального интерфейса ppp
PPTP_ADDR=$5              # Внутренний IP адрес клиента
LOCAL_NET_IF="eth0"       # Локальный интерфейс нашего сервера

# разрешаем проходжение пакетов между локальной сетью и клиентом
iptables -A FORWARD -i ${PPTP_IF}  -o ${LOCAL_NET_IF} -j ACCEPT
iptables -A FORWARD -i ${LOCAL_NET_IF} -o ${PPTP_IF} -j ACCEPT
# разрешаем входящие пакеты с нашего сервера к клиенту
iptables -A INPUT -i ${PPTP_IF} -j ACCEPT

Так же при отключении запускается скрипт который удаляет эти маршруты.

При всем этом, с телефона все работает отлично. То есть подключение к впн на телефоне идет удачно, страницы пашут и все в порядке. А с компа нет.

Подскажите пожалуйста, что я делаю не так и в чем причина?



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

Начните с MTU, с помощью iptables ″-j TCPMSS″ попробуйте на время установить низкий mss (допустим ″--set-mss 800″).

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

В принципе ничего не изменилось.

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

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

-A FORWARD -i ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 800

Вот так выглядит правило. На счет mangle что-то я не в курсе. Подскажите.

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

Согласно man'у правило TCPMSS должно быть в таблице mangle. То есть

iptables -t mangle -I FORWARD -i ppp+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 800

при условии, что клиенту выдаётся интерфейс ppp.

В том виде, что вы написали, правило лишено смысла. Хотя в некоторых ядрах TCPMSS правило сработает в таблице filter в цепочке FORWARD, но, ″-A″ означает добавить правило в конце списка. А в вашем случае у вас для ваших windows клиентов фактически будут работать два правила в FORWARD:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
... -A FORWARD -i ppp+ -j ACCEPT

Даже правила, добавляемые из /etc/ppp/ip-up.local, кажется, бессмыслены, потому что добавляются после
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

А ещё есть команда ″iptables -L -n -v -x″ и её вариант с ″-t mangle″, которая выводит счётчики iptables, что позоволяет судить, срабатывало ли правило или нет. То есть сначала смотрите счётчики, потом пытаетесь открыть страницу, потом снова смотрите счётчики. Если страница не открывается, а счётчик TCPMSS вырос, значит дело не в MTU.

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