PPTP over PPPoE, маршруты и DNS.. вопросы

Автор gardarea51, 18 апреля 2013, 21:02:11

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

gardarea51

Всем привет!  :)

На работе встала задача включаться в КИС головной организации, используя VPN-туннель, то есть PPTP. Сам же интернет у нас приходит через PPPoE. Получается, что нужно прокинуть PPTP через PPPoE, а потом пустить в него клиентов локальной сети через NAT. С этим вроде сложностей нет.. однако, есть кое-какое непонимание. Завтра допишу еще вопросы и предположения, а пока только спрошу.

На винде при подключении по VPN роуты получаются автоматически, наверное она получает их от сервера. У меня такое предположение, что она получает маршруты от DHCP, который выдает ей адрес через pptp - туннель. Так ли это? Если так, то думается мне, что аналогичный прием роутов можно настроить и на Debian, который является шлюзом для моей сети, но клиентом для pptp-сервера.

315th

#1
ЦитироватьУ меня такое предположение, что она получает маршруты от DHCP, который выдает ей адрес через pptp - туннель. Так ли это?
Всё так. После установления соединения с pptp-сервером клиент отправляет запрос по bootp (DHCPINFORM) через туннель на dhcp-сервер, dhcp-сервер отвечает на запрос клиента (DHCPAСK)
Открыть содержимое (спойлер)
У меня ситуация как раз наоборот: сервер с Debian занимается туннелями и выдачей маршрутизации.
[свернуть]
Вероятно может подойти следующее:
- пересобрать dhcp-client с поддержкой ppp-интерфейсов (патчи есть в рассылках isc.org или тут) и в post-up запускать с нужными запросами.

Насколько это будет работоспособно на Debian затрудняюсь ответить, но факт в том, что подобные решения работают в embedded-Linux (netgear, dlink, etc.)
Debian GNU/Linux 7.11 (wheezy) - CLI
ICH7; D525MV; r8169; Linux 4.14.32-atomd525mv-imq-ja1 (i686); Intel Atom D525 1.8 GHz

gardarea51

Проблему решил.. в понедельник постараюсь описать как. В общем-то все оказалось довольно банально. Извиняюсь, что сам забыл про тему. =)

315th

Опишите, пожалуйста, действительно интересно.
Debian GNU/Linux 7.11 (wheezy) - CLI
ICH7; D525MV; r8169; Linux 4.14.32-atomd525mv-imq-ja1 (i686); Intel Atom D525 1.8 GHz

gardarea51

Итак :) Быстро и кратко наверное не получится, но я постараюсь не вдаваться в детали частного исполнения.

Интернет в контору приходит через PPPoE по ADSL - линии (скоро наверное будет L2TP по оптике, но пока так). Для связи с ресурсами головной конторы (для активации Windows через KMS) стало нужно использовать VPN-соединение типа PPTP. То есть получается PPTP over PPPoE.

Что важно, VPN-канал не дает возможности выхода в Интернет, то есть в Интернет моя контора должна продолжать ходить через местное PPPoE-соединение.

Каков в общем порядок действий, что нужно сделать:
1) Настроить PPPoE-соединение (либо уже иметь его настроенным)
2) Настроить PPTP-соединение
3) Описать эти соединения в /etc/network/interfaces
4) Дополнить работу PPTP-соединения автоматическим поднятием/удалением нужных маршрутов
5) Настроить DNS для того, чтобы нужные запросы уходили на DNS-сервера головной конторы.

Фаза 1: настройка/донастройка PPPoE-соединения.
За настройку PPPoE-соединения отвечают 3 файла, это:

  • /etc/ppp/options - основной файл опций для всех pppoe-соединений
  • /etc/ppp/peers/dsl-provider - файл с описанием pppoe-соединения, обозванный "dsl-provider" (имя может быть любым)
  • /etc/ppp/pap-secrets - файл секретов для pppoe-соединений

По порядку привведу содержимое всех 3х файлов. Первый - файл глобальных опций для PPPoE. Тут все стандартно за исключением пары параметров, которые отвечают за бесконечный дозвон и восстановление соединения при его обрыве:?
cat /etc/ppp/options
asyncmap 0
auth
crtscts
lock
hide-password
modem
mtu 1492
lcp-echo-interval 30
lcp-echo-failure 5
noipx
persist
maxfail 0


Второй файл содержит описание конкретного соединения (пира). Опции этого файла имеют более высокий приоритет, чем опции в вышеприведенном файле. Также здесь указано, что для соединения будет использован физ. интерфейс "wan", номер pppX всегда будет "0", что дает возможность получать соединение ppp0, а не ppp1, ppp2 и пр. Здесь также указано имя (логин), по которому будет выбран пароль из файла секретов. Ну и установка дефолтного маршрута, ведь это наша основная дырка в великий Интернет.
root@smb:~# cat /etc/ppp/peers/dsl-provider
plugin rp-pppoe.so

wan
unit 0
name "ЛогинPPPoE"
defaultroute

persist
maxfail 0

hide-password
noauth


Третий файл - файл секретов является очень простым. Самая важная его строка - самая нижняя. Она определяет пару логин-пароль. После просмотра файла конкретного пира (/etc/ppp/peers/dsl-provider) система будет искать для него пароль в файле секретов. В этом же файле кое-какие установки ограничений на использование соединений некоторыми пользователями, но это все у меня оставлено по умолчанию.
root@smb:~# cat /etc/ppp/pap-secrets
# INBOUND connections

# Every regular user can use PPP and has to use passwords from /etc/passwd
* hostname "" *

# UserIDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd!
guest hostname "*" -
master hostname "*" -
root hostname "*" -
support hostname "*" -
stats hostname "*" -

# OUTBOUND connections

# Here you should add your userid password to connect to your providers via
# PAP. The * means that the password is to be used for ANY host you connect
# to. Thus you do not have to worry about the foreign machine name. Just
# replace password with your password.
# If you have different providers with different passwords then you better
# remove the following line.

# * password

"ЛогинPPPoE"   *       "ПарольPPPoE"


Теперь после выполнения команды pon dsl-provider PPPoE соединение будет поднято, чтобы закрыть соединение выполняется команда poff dsl-provider. Можно запускать это вручную, но лучше автоматизировать, поэтому пишем в файл /etc/network/interfaces следующее:
root@smb:~# cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto wan
iface wan inet static
address 192.168.1.3
netmask 255.255.255.0

auto lan
iface lan inet static
address 192.168.2.1
netmask 255.255.255.0

auto dsl-provider
iface dsl-provider inet ppp
provider dsl-provider
dns-nameservers 127.0.0.1
pre-up /sbin/ifup wan

Я немного урезал вывод этого файла, убрав лишнее. Последние строки говорят то том, что ppp-соединение "dsl-provider" будет подниматься автоматически ("auto"), перед его поднятием нужно поднять физ. интерфейс "wan". Вот и все. Теперь PPPoE соединение можно запускать командой ifup, а разрывать соединение командой ifdown. К примеру так:
ifup dsl-provider
ifdown dsl-provider

Это debian'овские команды "автоматизации" управления сетью. Они позволяют настраивать разные варианты управления сетью и используют каталоги
root@smb:~# ls /etc/network
if-down.d  if-post-down.d  if-pre-up.d if-up.d  interfaces  run
Но я не буду останавливаться на этом подробно, просто упоминание. Стоит заметить, что эти каталоги не позволяют управлять ppp-соединениями (добавлять/удалять маршруты до/после/во время подключения и пр..). Для ppp-соединений есть свои каталоги "автоматизации" этих дел. О них будет сказано далее.

Фаза 2: настроить PPTP-соединение
За настройку PPTP-соединения отвечают также 3 файла, это:

  • /etc/ppp/options.pptp - файл глобальных опций для PPTP-соединений
  • /etc/ppp/peers/pptp_crp - файл описания PPTP-соединения (пира), имя может быть любым, у меня оно такое
  • /etc/ppp/chap-secrets - файл секретов для PPTP-соединений, устанавливающих пары логин/пароль

В первом файле опций у меня следующие опции (все практически стандартно):
root@smb:~# cat /etc/ppp/options.pptp
lock
noauth
nobsdcomp
nodeflate

refuse-pap
refuse-eap
refuse-chap
#refuse-mschap

Во втором файле (файле описания конкретного соединения - пира) у меня написано следующее:
root@smb:~# cat /etc/ppp/peers/pptp_crp
pty "pptp vpn.subdomain.company.ru --nolaunchpppd"
name "DOMAIN\\ЛогинVPN"
remotename PPTP
file /etc/ppp/options.pptp
ipparam pptp_crp

require-mppe-128
#defaultroute
#replacedefaultroute

persist
maxfail 0

#usepeerdns
unit 5

Здесь указывается строка инициализации подключения, которая содержит адрес VPN-сервера, к которому мы будем подключаться, далее идет имя пользователя с указанием домена (если он есть, это те параметры, которые обычно выдает провайдер для подключения). Далее указывается имя туннеля ("ipparam", оно совпадает с именем самого пира "pptp_crp"), бесконечный дозвон, "номер" pppX, который в текущем случае равен 5, чтобы сосединение всегда было ppp5 и никакое другое. Здесь же у меня закомментированный параметр usepeerdns ("использовать полученные DNS"), вполне возможно, что вам нужно будет его раскомментировать, то же самое касается и параметра "defaultroute" (установить дефолтный маршрут через запущенное VPN-соединение, для меня это было лишнее, я ограничился маршрутами, о них далее).

Файл секретов для PPTP, тут все тоже стандартно по аналогии с PPPoE:
root@smb:~# cat /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses

"DOMAIN\\ЛогинVPN"         PPTP    "PPTP_Пароль"    *


Теперь соединение можно запускать командами pon и poff, по аналогии с PPPoE-соединением:
pon pptp_crp
poff pptp_crp


Фаза 3: описать соединения в /etc/network/interfaces

Для автоматизации поднятия соединения можно внести правки в /etc/network/interfaces (мой файл несколько сокращен):
root@smb:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto wan
iface wan inet static
address 192.168.1.3
netmask 255.255.255.0

auto lan
iface lan inet static
address 192.168.2.1
netmask 255.255.255.0

auto dsl-provider
iface dsl-provider inet ppp
provider dsl-provider
dns-nameservers 127.0.0.1
pre-up /sbin/ifup wan
post-up /sbin/ifup pptp_crp
pre-down /sbin/ifdown pptp_crp

#auto pptp_crp
iface pptp_crp inet ppp
provider pptp_crp
        #pre-up /sbin/ifup dsl-provider - можете раскомментировать, это один из вариантов "автоматизации всего и вся"


После этих манипуляций соединение можно запускать командой ifup pptp_crp разрывать командой ifdown pptp_crp Кроме того, соединение будет подниматься автоматически при старте системы или же выполнении команды service networking restart

Фаза 4: Дополнить работу PPTP-соединения автоматическим поднятием/удалением нужных маршрутов

Для автоматизации прописывания/удаления маршрутов при ppp-соединениях используются следующие файлы и каталоги:
/etc/ppp/ip-down 
/etc/ppp/ip-up
/etc/ppp/ip-down.d
/etc/ppp/ip-up.d


Вы можете открыть и посмотреть файлы
/etc/ppp/ip-down 
/etc/ppp/ip-up

В них описано в частности следующее, если в каталогах
/etc/ppp/ip-down.d
/etc/ppp/ip-up.d
будут найдены исполняемые файлы с именем ppp-туннеля ("ipparam"), то они будут выполнены. Но есть одно но! Они будут выполнены для каждого ppp-соединения. У нас ipparam=pptp_crp, поэтому я создал файл
root@smb:~# cat /etc/ppp/ip-up.d/pptp_crp
#!/bin/bash


if [ "$PPP_IPPARAM" = "pptp_crp" ]; then
#Прописывание роутов до КИС
ip route add 10.0.0.0/8 via $PPP_LOCAL dev $PPP_IFACE
ip route add xxx.xxx.xxx.0/20 via $PPP_LOCAL dev $PPP_IFACE
#Роут до сервера активации KMS
ip route add xxx.xxx.xxx.xxx via $PPP_LOCAL dev $PPP_IFACE
        exit 0
fi

Файл нужно сделать исполняемым и начать его со строки #!/bin/bash. Этот файл делает только одно: прописывает нужные маршруты после поднятия соединения, но только если туннель имеет имя "pptp_crp". Переменные, используемые в скрипте можно посмотреть в вышеупомянутых скриптах /etc/ppp/ip-down и /etc/ppp/ip-up.

Для аналогичного удаления маршрутов при разрыве соединения создается файл
root@smb:~# cat /etc/ppp/ip-down.d/pptp_ustu
#!/bin/bash

if [ "$PPP_IPPARAM" = "pptp_crp" ]; then
        #Удаление роутов до КИС
        ip route del 10.0.0.0/8 via $PPP_LOCAL dev $PPP_IFACE
        ip route del xxx.xxx.xxx.0/20 via $PPP_LOCAL dev $PPP_IFACE
        #Удаление роута до сервера активации KMS
        ip route del xxx.xxx.xxx.xxx via $PPP_LOCAL dev $PPP_IFACE
        exit 0
fi

Эти файлы здесь содержат важные только для меня маршруты. При соединении по pptp_crp я получаю интерфейс ppp5, который как правило имеет адрес из диапазона 10.0.0.0/8. Обычно так оно и бывает, поэтому маршрут до этого диапазона является пожалуй стандартным для всех соединений по pptp.

Фаза 5: настроить DNS для того, чтобы нужные запросы уходили на DNS-сервера головной конторы.

Вполне возможно, что вам не придется выполнять все нижеописанное, достаточно раскомментировать параметр usepeerdns в файле /etc/ppp/peers/pptp_crp и вы автоматически получите нужные DNS-адреса при поднятии соединения.

Очень важный момент заключается в том, чтобы до инициализации pptp-соединения ваша система смогла преобразовать имя сервера VPN в IP-адрес, то есть у вас еще до поднятия pptp-соединения должен быть указан какой-либо DNS (скажем в /etc/resolv.conf), который сможет обеспечить вам такое преобразование.

У меня все несколько иначе. На том же компьютере, на котором работает PPPoE и PPTP, дополнительно трудится DNS-сервер bind9. В /etc/resolv.conf у меня только 1 запись DNS:
root@smb:~# cat /etc/resolv.conf
domain local
search local
nameserver 127.0.0.1


То есть все DNS-запросы идут на 127.0.0.1 к bind9. В моем случае он обрабатывает эти запросы путем переадресации их на другие DNS-сервера.

Это:
1) внешние DNS - гуглDNS,
2) внутренние DNS головной конторы.

С внешними все понятно. А переадресация на внутренние выглядит у меня примерно так (вывод немного урезан):
root@smb:~# cat /etc/bind/named.conf.local
#Форвард запросов к зонам (.company, .company.ru) на DNS-сервера Company
zone "company" IN {
      type forward;
      forward only;
      forwarders { 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 93.xx.xx.2; xx.xx.xx.2; };
};
zone "company.ru" IN {
      type forward;
      forward only;
      forwarders { 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 10.xx.xx.2; 93.xx.xx.2; xx.xx.xx.2; 8.8.8.8; 8.8.4.4; };
};


Естественно, при таком подходе адреса DNS-серверов лучше знать изначально, кроме того, они могут измениться и их нужно будет изменить в этом файле. Посмотреть список DNS-серверов в самом простом случае можно в Windows после установки VPN-подключения на ней.

Что дает эта конструкция? Она дает то, что при попытке установки PPTP-подключения к vpn.subdomain.company.ru запрос обработается последними в списке гуглDNS'ами и вернет реальный IP-адрес хоста vpn.subdomain.company.ru. Далее, после установки подключения в дело вступят внутренние DNS-серверы, которые запрашиваемые имена из доменов company.ru и company будут обрабатывать до того, как очередь дойдет до гуглDNS. То есть кто первым ответил - тот и молодец. А заспросы к company.ru и company _желательно_ обрабатывать через внутренние DNS, потому как:

если запрос на преобразование имени (к примеру srv.company.ru) пришел из корп. сети (по маршруту 10.0.0.0/8 для pptp_crp он пойдет именно там), то внутренний DNS-сервер очень вероятно выдаст на этот запрос внутренний IP-адрес хоста srv.company.ru (10.хх.хх.хх) и мы сможем получить доступ до этого хоста из внутреней корп. сети. В то же время хост srv.company.ru снаружи этой сети может иметь совершенно другой внешний IP-адрес или вовсе его не иметь.

Но вообще, возможно, вам это совсем не понадобится, просто попробуйте использовать опцию usepeerdns. На этом все, надеюсь, что написал не слишком запутанно..

315th

В целом довольно понятно. Жаль, что решение оказалось именно таким - ifupdown, т.е никакой выдачи маршрутизации в туннеле через option 121 и 249.
Я попробовал натравить udhcpc на туннельный интерфейс

root@debtest:/home/sid# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.10.99  P-t-P:192.168.10.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:7 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:70 (70.0 B)  TX bytes:70 (70.0 B)

root@debtest:/home/sid# udhcpc -B -i ppp0
udhcpc (v1.20.2) started
Sending discover...
Sending select for 192.168.10.170...
Lease of 192.168.10.170 obtained, lease time 18000
/etc/udhcpc/default.script: Resetting default routes
SIOCDELRT: No such process
/etc/udhcpc/default.script: Adding DNS 192.168.10.1
root@debtest:/home/sid# ifconfig ppp0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.10.170  P-t-P:192.168.10.170  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:726 (726.0 B)  TX bytes:698 (698.0 B)

root@debtest:/home/sid#

На dhcp-сервере получил следующее

root@server:/var/log# tail -f dhcpd.log
Apr 29 13:53:02 server dhcpd: DHCPDISCOVER from 00:00:00:00:00:00 via vlan6
Apr 29 13:53:03 server dhcpd: DHCPOFFER on 192.168.10.170 to 00:00:00:00:00:00 via vlan6
Apr 29 13:53:03 server dhcpd: DHCPREQUEST for 192.168.10.170 (192.168.10.1) from 00:00:00:00:00:00 via vlan6
Apr 29 13:53:03 server dhcpd: DHCPACK on 192.168.10.170 to 00:00:00:00:00:00 via vlan6

Похоже что оно работает, осталось только наложить патчи на busybox для поддержки option 121 и 249 и поправить /etc/udhcpc/default.script, думаю, что вполне может получится.
Debian GNU/Linux 7.11 (wheezy) - CLI
ICH7; D525MV; r8169; Linux 4.14.32-atomd525mv-imq-ja1 (i686); Intel Atom D525 1.8 GHz

gardarea51

Да, в общем это было бы интересно, но не хочется патчить, потому как при обновлении или каком-либо другом действии можно получить трабл.

315th

#7
Наверное сейчас уже не актуально, но тем не менее...  вопрос с получением маршрутизации по опциям 141 и 249 через pptp-туннель решил. Решение лежало как раз через udhcpc.
Патчить udhcpc не пришлось, оно и так поддерживает нужные dhcp-option. Скорее всего можно использовать штатный udhcpc в пакете, я решил собрать отдельный бинарник. Поправил только скрипт udhcpc.
В итоге получилось следующее:
В /etc/ppp/ip-up.d/ создал файл classless_routes

#!/bin/sh
/etc/ppp/udhcpc -aqnBS -t 6 -i $PPP_IFACE -C -O121 -O249 -x lease:300 -s /etc/ppp/default.script -p /var/run/udhcpc.$PPP_IFACE.pid

В  /etc/ppp/ создал скрипт для udhcpc.

#!/bin/sh

case $1 in
    bound|renew)
        network=$(ipcalc $ip/$subnet | awk '/Network:/{print $2}')
        [ -n "$staticroutes" ] && classes_route=$(echo "$staticroutes" | sed -e "s/$router//g")
        [ -n "$msstaticroutes" ] && classes_route=$(echo "$msstaticroutes" | sed -e "s/$router//g")
        ip route add $network dev $interface
        for rt in $classes_route; do
                ip route add $rt dev $interface
        done
        ;;

    *)
        exit 1
        ;;
esac

В результате маршрутизация получается через туннель по 121 и 249 option.
результат с целевой машины

# ifconfig
3g0       Link encap:Point-to-Point Protocol
          inet addr:10.211.91.146  P-t-P:10.6.6.6  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:527 errors:0 dropped:0 overruns:0 frame:0
          TX packets:632 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:58179 (56.8 KiB)  TX bytes:70276 (68.6 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vpn0      Link encap:Point-to-Point Protocol
          inet addr:192.168.0.38  P-t-P:192.168.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:337 errors:0 dropped:0 overruns:0 frame:0
          TX packets:305 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:31354 (30.6 KiB)  TX bytes:38480 (37.5 KiB)
#  route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 3g0
10.6.6.6        0.0.0.0         255.255.255.255 UH    0      0        0 3g0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 vpn0
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 vpn0
192.168.1.0     0.0.0.0         255.255.255.224 U     0      0        0 vpn0
213.141.136.40  0.0.0.0         255.255.255.248 U     0      0        0 vpn0
213.141.136.41  0.0.0.0         255.255.255.255 UH    0      0        0 3g0
#
[свернуть]
Debian GNU/Linux 7.11 (wheezy) - CLI
ICH7; D525MV; r8169; Linux 4.14.32-atomd525mv-imq-ja1 (i686); Intel Atom D525 1.8 GHz