Итак имеем сервер с CentOS 5.5 выступающий в качестве основного шлюза, один интерфейс с адресом 192.168.1.1 смотрит в локальную сеть 192.168.1.0/24, другой интерфейс с адресом 10.10.11.25 в интернет (адрес внешнего интерфейса выбран исключительно для примера).

1. Установка PPTP

Устанавливаем PPTP-сервер:

[root@localhost tmp]# wget http://poptop.sourceforge.net/yum/stable/rhel5/pptp-release-current.noarch.rpm
[root@localhost tmp]# rpm -i pptp-release-current.noarch.rpm
[root@localhost tmp]# yum install pptpd

2. Настройка PPTP-сервера

Разрешаем форвард пакетов, в файле /etc/sysctl.conf меняем значение net.ipv4.ip_forward с 0 на 1. Обновляем параметры командой

[root@localhost ~]# sysctl -p

Загружаем необходимые для работы протокола PPTP через NAT модули. Чтобы модули подгружались при загрузке системы эти команды необходимо добавить в файл /etc/rc.d/rc.local.

[root@localhost ~]# modprobe ip_gre
[root@localhost ~]# modprobe ip_nat_pptp
[root@localhost ~]# modprobe ip_conntrack_pptp

Добавляем в файл /etc/pptpd.conf, адрес шлюза и список адресов выдаваемых клиентским компьютера.

localip 192.168.1.1          # адрес шлюза
remoteip 192.168.1.200-250   # список выдаваемых адресов

Переходим к конфигурационному файлу /etc/ppp/options.pptpd

# имя сервера - используется для аутентификации
name pptpd
# Список протоколов проверки пароля
refuse-pap            # Незашифрованный пароль PAP
refuse-chap           # Протокол проверки пароля CHAP
refuse-mschap         # Протокол проверки пароля MS-CHAP
require-mschap-v2     # Протокол проверки пароля MS-CHAP v2
require-mppe-128      # Использоавть MPPE128 шифрование при проверке пароля
                      # MS-CHAP v2
ms-dns 192.168.1.2    # По умолчанию параметр закоментирован, используется
                      # для передачи параметров локального DNS-сервера
                      # клиентскому ПК
ms-wins 192.168.1.2   # По умолчанию параметр закоментирован, используется
                      # для передачи параметров локального WNS-сервера
                      # клиентскому ПК

Добавляем пользователей. Для PAP-аутентификации используется файл /etc/ppp/pap-secrets, для CHAP/MSCHAP – /etc/ppp/chap-secrets. Оба файла имеют по сути одинаковую структуру.

# client        server  secret                  IP addresses
# client - имя пользователя
# server - имя указанное в файле /etc/ppp/options.pptpd в параметре name
# secret - пароль пользователя
# IP adresses - список адресов с которых пользователю разрешен доступ к серверу
#         "*" - доступ разрешен с любого адреса.
user1           pptpd   123456                  "*"
user2           pptpd   142536                  "*"

Включаем в автозагрузку и запускаем сервис pptpd

[root@localhost ~]# chkconfig pptpd on
[root@localhost ~]# service pptpd start
Starting pptpd:                                            [  OK  ]

3. Настройка IPTABLES

Для каждого конкретного случая настройка iptables может быть очень специфичной, здесь я опишу настройку некоторого базового варианта: интерфейс eth0 – смотрит в инет, интерфейс eth1 – локальная сеть; политики по умолчанию INPUT DROP (входящий трафик запрещен) , FORWARD DROP (форвардинг пакетов запрещен), OUTPUT ACCEPT (исходящий трафик разрешен).

Разрешаем  входящие подключения на TCP порт 1723 и по протоколу GRE через внешний интерфейс eth0.

[root@localhost ~]# iptables -A INPUT -i eth0 -p gre -j ACCEPT
[root@localhost ~]# iptables -A INPUT -i eth0 -m tcp -p tcp --dport 1723 -j ACCEPT
[root@localhost ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

При создании каждого подключения pptp создается виртуальный интерфейс ppp, этому интерфейсу присваивается внутренний адрес VPN-клиента. Когда клиент одни все просто – пара разрешающих правил и все готово, но когда клиентов становится больше остаются два варианта: либо смягчить правила разрешив доступ со всех интерфейсов ppp и всего пула remoteip в локальную сеть и обратно, либо создавать и удалять правила динамически. Второй вариант на мой взгляд явно лучше.

Создаем файл скрипта для открытия подключения /etc/ppp/ip-up.local, этот скрипт будет запускаться автоматически после создания интерфейса ppp при подключении клиента.

#!/bin/sh
PPTP_IF=$1                # Имя виртуального интерфейса ppp
PPTP_ADDR=$5              # Внутренний IP адрес клиента
LOCAL_NET_IF="eth1"       # Локальный интерфейс нашего сервера
 
# разрешаем проходжение пакетов между локальной сетью и клиентом
iptables -A FORWARD -i ${PPTP_IF} -s ${PPTP_ADDR} -o ${LOCAL_NET_IF} -j ACCEPT
iptables -A FORWARD -i ${LOCAL_NET_IF} -d ${PPTP_ADDR} -o ${PPTP_IF} -j ACCEPT
# разрешаем входящие пакеты с нашего сервера к клиенту
iptables -A INPUT -i ${PPTP_IF} -j ACCEPT

Создаем файл скрипта для закрытия подключения /etc/ppp/ip-down.local, этот скрипт будет автоматически запускаться перед удалением интерфейса ppp при отключении клиента.

#!/bin/sh
PPTP_IF=$1                # Имя виртуального интерфейса ppp
PPTP_ADDR=$5              # Внутренний IP адрес клиента
LOCAL_NET_IF="eth1"       # Локальный интерфейс нашего сервера
 
# удаляем правила созданные скриптом ip-up.local
iptables -D FORWARD -i ${PPTP_IF} -s ${PPTP_ADDR} -o ${LOCAL_NET_IF} -j ACCEPT
iptables -D FORWARD -i ${LOCAL_NET_IF} -d ${PPTP_ADDR} -o ${PPTP_IF} -j ACCEPT
iptables -D INPUT -i ${PPTP_IF} -j ACCEPT

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

4. Заключение.

PPTP достаточно прост в установке и настройке. Одно из преимуществ – не требует от конечного пользователя каких либо серьезных навыков и знаний в области компьютерных технологий для настройки подключения, которое легко организуется за счет штатных средств современных ОС.

Главные недостатки заставляющие смотреть с торону других протоколов – низкая защищенность передаваемых данных и слабая устойчивость к атакам.

21 Коммент. : “Установка PPTP-сервера на CentOS”

  1. shell пишет:

    надо еще в добавок разрешить входящие по протоколу 47

  2. Alsigned пишет:

    @shell
    47 – это протокол GRE. Входящие соединения по нему были разрешены командой
    iptables -A INPUT -p gre -j ACCEPT

  3. Я бы еще бы кратко написал, какую авторизацию лучше использовать и почему. Потому как часть вариантов для публичного инет слишком дырявая, а часть хреново работает.

  4. Странная штука.
    Похоже инструкция написана не до конца. :)
    PPTP работает, подключается, но пакеты не бегают.
    удаленная сеть 192.168.1.0
    адрес PPTP 192.168.1.180
    выдаваемый PPTP адрес 192.168.1.230
    Локальный адрес на подключаемой машине 192.168.0.150
    Подключение проходит, но пакеты в 192.168.1.0 подсеть не ходят. Пинги впрочем тоже.
    Т.е. похоже? для работоспособности надо разрешить PPP0 на IPTABLES и возможно добавить правил route

  5. гм.
    iptables -A INPUT -i ppp0 -j ACCEPT
    iptables -A OUTPUT -o ppp0 -j ACCEPT
    пинг ходит, а радмин к удаленке всё равно не подключается

  6. О!
    Нашел.
    Как все очевидное, нашлось не сразу…
    iptables -A FORWARD -o eth0 -i ppp0 -j ACCEPT
    iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT

  7. Alsigned пишет:

    @miha
    Спасибо за ценные исправления.
    И вправду статья немного сыровата и имеет ряд недочетов. Особенно в плане настройки iptables, которые я по доброте душевной просто отключил на время настройки и тестирования.

    PS: Ошибку признаю – исправлюсь )

  8. Николай пишет:

    Поправь статью, чтобы с первого раза было все нормально…
    Статья мне очень пригодилась, спасибо ;)

  9. Alsigned пишет:

    @Николай
    Привет.

    Если ты имеешь ввиду настройку iptables о которой говорил miha, то я уже исправился и дописал все что нужно к статье – “3. Настройка iptables” написана как-раз после его комментариев.

    Если есть что-то новое пиши – поправлю. Я за то – что бы делать правильные и полезные статьи ;)

  10. как быть подскажите!!??
    клиент подключился и отвалился через определенное время на сервере сессия висит клиент пробует подключится проходит авторизацию получает тот же апи но из-за зависшей сессии у него ни чего не работает …. как сделать так чтобы сессии само проверялись на работоспособность со стороны сервера… и убивались если не поступил ответ!
    апи статики так нужно для работы удаленных офисов, динамика не подходит

  11. Ave пишет:

    Указанные в статье модули, если я не ошибаюсь, нужны только для настройки проброса туннеля через NAT, т.е. если сам VPN сервер стоит за NAT и мы к нему пытаемся подключиться через какой-нибудь linux’овый роутер.

  12. Ave пишет:

    У меня VPN сервер на отдельном компьютере, с двумя интерфейсами – один смотрит в локальную сеть, а другой в инет.
    iptables на время проверки отключил, SELinux тожe
    ip_forward = 1
    Из инета подключаюсь по VPN, получаю IP из локальной сети, но ни один компьютер из локалки не пингуется, и из локалки этот ip не пропинговать. В чем может быть проблема?

  13. Alsigned пишет:

    А модули загружены?
    modprobe ip_gre
    modprobe ip_nat_pptp
    modprobe ip_conntrack_pptp

    Что в логах пишет после установки соединения?

  14. Ave пишет:

    Модули оказались не причем.
    Прописал в iptables правило
    iptables -t nat -A POSTROUTING -s remoteip -j SNAT –to-source localip
    и пинги пошли…
    Хотя где-то читал, что если включен параметр proxyarp, то postrouting не нужен.

  15. Alsigned пишет:

    Получается ты натишь пакеты из подсети N в туже подсеть N и после этого начинают ходить пинги. Я правильно понимаю?

  16. Ave пишет:

    Да, именно так.

  17. Ave пишет:

    Проблема оказалась в proxyarp.
    При поднятии туннеля pptpd добавляет запись в arp таблицу pptpd сервера, чтобы отвечать на ARP запросы по IP VPN-клиента, но только на локальном интерфейсе.
    После добавления такой же записи только для внешнего интерфейса – все заработало. Пришлось скрипт запуска подправить согласно man’у PoPToP (http://poptop.sourceforge.net/dox/howto.html), чтобы он добавлял соответствующую arp запись и на внешний интерфейсе.

  18. Drill пишет:

    PPTP_ADDR=$5 Почему $5, а не $6?

  19. Дмитрий пишет:

    Помогите решить проблему. Удаленные vpn-клиенты, если некоторое время не производят обмен данными по тунелю – отваливаются, то есть у них на компах vpn-соединение с виду выглядит как подключённое, но связь с vpn-сервером теряется, приходится переподключаться. В чем причина? Как устранить? Подскажите пожалуйста.

  20. gr1mm3r пишет:

    Вскопаю я этот могильничек
    >Единственное жалко, что скрипту не передается в параметрах имя пользователя – можно было более детально разграничить доступ к ресурсам: одним – одни ресурсы, другим – другие.
    —-
    Немного не верно.
    Есть такая штука как PEERNAME
    пруф по теме
    http://www.opennet.ru/openforum/vsluhforumID1/90335.html#1
    там и расписано собственно все

Оставить комментарий