Автор Тема: PPTP over PPPoE, маршруты и DNS.. вопросы  (Прочитано 9370 раз)

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

Оффлайн gardarea51

PPTP over PPPoE, маршруты и DNS.. вопросы
« : 18 Апреля 2013, 21:02:11 »
Всем привет!  :)

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

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

Оффлайн 315th

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #1 : 24 Апреля 2013, 21:40:14 »
Цитировать
У меня такое предположение, что она получает маршруты от DHCP, который выдает ей адрес через pptp - туннель. Так ли это?
Всё так. После установления соединения с pptp-сервером клиент отправляет запрос по bootp (DHCPINFORM) через туннель на dhcp-сервер, dhcp-сервер отвечает на запрос клиента (DHCPAСK)
Spoiler: ShowHide
У меня ситуация как раз наоборот: сервер с Debian занимается туннелями и выдачей маршрутизации.

Вероятно может подойти следующее:
- пересобрать dhcp-client с поддержкой ppp-интерфейсов (патчи есть в рассылках isc.org или тут) и в post-up запускать с нужными запросами.

Насколько это будет работоспособно на Debian затрудняюсь ответить, но факт в том, что подобные решения работают в embedded-Linux (netgear, dlink, etc.)
« Последнее редактирование: 16 Августа 2013, 01:07:09 от 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

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #2 : 26 Апреля 2013, 21:20:39 »
Проблему решил.. в понедельник постараюсь описать как. В общем-то все оказалось довольно банально. Извиняюсь, что сам забыл про тему. =)
 

Оффлайн 315th

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #3 : 27 Апреля 2013, 01:17:55 »
Опишите, пожалуйста, действительно интересно.
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

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #4 : 29 Апреля 2013, 12:22:27 »
Итак :) Быстро и кратко наверное не получится, но я постараюсь не вдаваться в детали частного исполнения.

Интернет в контору приходит через 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

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #5 : 29 Апреля 2013, 13:58:38 »
В целом довольно понятно. Жаль, что решение оказалось именно таким - 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

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #6 : 29 Апреля 2013, 14:25:33 »
Да, в общем это было бы интересно, но не хочется патчить, потому как при обновлении или каком-либо другом действии можно получить трабл.
 

Оффлайн 315th

Re: PPTP over PPPoE, маршруты и DNS.. вопросы
« Ответ #7 : 10 Августа 2014, 10:48:33 »
Наверное сейчас уже не актуально, но тем не менее...  вопрос с получением маршрутизации по опциям 141 и 249 через pptp-туннель решил. Решение лежало как раз через udhcpc.
Патчить udhcpc не пришлось, оно и так поддерживает нужные dhcp-option. Скорее всего можно использовать штатный udhcpc в пакете, я решил собрать отдельный бинарник. Поправил только скрипт udhcpc.
В итоге получилось следующее:
В /etc/ppp/ip-up.d/ создал файл classless_routes
Код: (bash) [Выделить]
#!/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.
Код: (bash) [Выделить]
#!/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.
результат с целевой машины: ShowHide

# 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
#

« Последнее редактирование: 29 Марта 2015, 15:13:22 от 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
 

Теги:
     

    VPN (PPTP - трудности) [РЕШЕНО]

    Автор Bondarenko

    Ответов: 5
    Просмотров: 2267
    Последний ответ 12 Апреля 2013, 19:40:08
    от Bondarenko
    Проблемы с настройко pptp

    Автор k0matoznik

    Ответов: 7
    Просмотров: 2385
    Последний ответ 22 Декабря 2015, 08:18:41
    от k0matoznik
    поднятие туннеля PPTP через NAT на Debian

    Автор Izolda

    Ответов: 0
    Просмотров: 964
    Последний ответ 07 Сентября 2017, 16:26:13
    от Izolda
    не могу осилить VPN соединение pptp

    Автор v_i_c

    Ответов: 8
    Просмотров: 4650
    Последний ответ 26 Марта 2012, 22:20:02
    от v_i_c
    igmpproxy + VPN PPTP

    Автор jidckii

    Ответов: 0
    Просмотров: 1653
    Последний ответ 05 Сентября 2014, 12:24:13
    от jidckii