The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"PPTP и передача роутинга windowns клиенту"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (VPN, IPSec)
Изначальное сообщение [ Отслеживать ]

"PPTP и передача роутинга windowns клиенту"  –1 +/–
Сообщение от vovan_sh (ok) on 28-Сен-11, 09:06 
Добрый день.

Столкнулся с проблемой. Есть необходимость подключения некоторых клиентов к VPN серверу через Интернет, для доступа на единственный хост в нашей подсети.
Сейчас клиенты подключаются через OpenVPN, но это немного проблематично - ставить на Win машины клиента OpenVPN и раздавать настройки с ключами.

Для упрощения настроек у клиента решено использовать дополнительно PPTP, т.к. клиент встроен у всех win по умолчанию, на сервере OpenBSD развернул пакет poptop, поднял pptpd. Настройки тривиальные из мануала:

cat /etc/ppp.conf
default:                                                              
  set log Phase Chat LCP IPCP CCP tun command                        
  disable ipv6cp                                                      
                                                                      
pptp:                                                                
  enable MSChapV2                                                    
  set mppe 128 stateless                                              
  disable deflate pred1                                              
  deny deflate pred1                                                  
  set timeout 0                                                      
  set ifaddr 192.168.99.1 192.168.99.10-192.168.99.200 255.255.255.255

прописал доступы в ppp.secrets

Тестирую подключение с машины с Windows XP:
Пользователь авторизуется нормально, получает динамический адрес от сервера, нужный хост ему доступен, как бы все ок. НО, у клиента по умолчанию роутинг на винде становится через IP адрес присвоенного PPTP интерфейсу. Соответственно, если клиент подключается через PPTP для получения доступа только к 1 сервису, у него перестает работать все остальное.
В настройках windows pptp можно убрать флажок - не использовать рутинг по умолчанию. Тогда Роутинг клиента не меняется, но для для доступа в нашу подсеть, надо выполнить команду route add. Короче не вариант.

Вообще как-то можно при подключении PPTP к серверу, раздать клиенту только один нужный маршрут, как это делается на openvpn, напр., push "route 10.1.2.30 255.255.255.255"?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от skeletor (ok) on 28-Сен-11, 10:26 
Передать роутинг посредством pptp - нельзя. Это может только openvpn.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "PPTP и передача роутинга windowns клиенту"  +2 +/–
Сообщение от GalaxyMaster email on 24-Апр-12, 10:41 
> Передать роутинг посредством pptp - нельзя. Это может только openvpn.

Иногда так умиляют люди, которые не имея опыта (или времени почитать стандарты) категорично заявляют вещи о которых понятия не имеют :))

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

ключевые слова для настройки - это DHCP (DHCPINFORM) и classless static routes.  Реализация, что работает у меня - это accel-pptp (настроен выдавать адреса) + dnsmasq (настроен не выдавать адреса, но отдавать DHCPPACK на DHCPINFORM).

Есть маленький caveat: Microsoft выпендрился и использует не стадартный DHCP option для stateless static routes: стандартный 121, MS вариант - 249 (я бы рекомендовал проаисывать оба -- так как некоторые системы все-таки следуют RFC).

Для чтения как устроена настройка маршрутов аосле учтановления VPN: http://technet.microsoft.com/en-us/library/cc779919(v=ws.10).aspx#w2k3tr_vpn_how_dkma

Вкратце: после того как тунель поднят, клиент пропихивает запрос через DHCPINFORM на кучку всего, в том числе и на опцию 249 -- просто надо на это ответить и клиент отконфигурится.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "PPTP и передача роутинга windowns клиенту"  –1 +/–
Сообщение от skeletor (ok) on 24-Апр-12, 11:48 
> Иногда так умиляют люди, которые не имея опыта (или времени почитать стандарты)
> категорично заявляют вещи о которых понятия не имеют :))

Так пишут люди, которые слышали звон да не знают где он :)

Что бы разрешить спор (думаю так будет правильнее всего) приведите сюда ваши настройки на которых всё работает и при этом виндовый клиент при подключении получает нужные маршруты.
А бросать ссылки и уходить от первоначальной темы - для этого большого ума не надо.

ПС. Без приведённых практических примеров доказывать что это возможно - просто троллить.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "PPTP и передача роутинга windowns клиенту"  +4 +/–
Сообщение от GalaxyMaster email on 24-Апр-12, 14:06 
>> Иногда так умиляют люди, которые не имея опыта (или времени почитать стандарты)
>> категорично заявляют вещи о которых понятия не имеют :))
> Так пишут люди, которые слышали звон да не знают где он :)

Ну, у меня в этой связке крутится около десятка VPN серверов (у разных клиентов), так что, я, думаю, что я как бы в теме.  Есть ли опыт у вас дерлоймента PPTP VPN'а на организации с 200-300 road warrior'ов, вот в чем вопрос :)) .  Я этим на хлеб зарабатываю :).

> ПС. Без приведённых практических примеров доказывать что это возможно - просто троллить.

Ради бога, только чего приводить - все ж просто:
=== accel-ppp.conf ===

[root@vpn ~]# cat /opt/accel-ppp/config/accel-ppp.conf
[modules]
log_syslog
pptp
l2tp
auth_mschap_v2
ippool
sigchld
chap-secrets
logwtmp

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=1
min-mtu=1280
mtu=1400
mru=1400
check-ip=1
single-session=replace
mppe=require
ipv4=require
ipv6=deny
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=0:0:0:2
ipv6-accept-peer-intf-id=1

[lcp]
lcp-echo-interval=30
lcp-echo-failure=3

[auth]
#any-login=0
#noauth=0

[pptp]
echo-interval=30
echo-failure=3
verbose=1

[l2tp]
host-name=access-vpn
verbose=1

[dns]
dns1=192.168.70.251
dns2=192.168.70.252

[client-ip-range]
disable

[ip-pool]
gw-ip-address=192.168.99.254
192.168.99.1-253

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
log-debug=/var/log/accel-ppp/debug.log
copy=1
level=3

[chap-secrets]
gw-ip-address=192.168.99.254
chap-secrets=/etc/ppp/chap-secrets

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001

[root@vpn ~]#
===

теперь dnsmasq, который обслуживает DHCPINFORM'ы -- я весь конфиг приводить не буду, он очень большой, нам интересен только DHCP там:
===
[root@vpn ~]# grep -E '^dhcp' /etc/dnsmasq.conf
dhcp-range=192.168.82.254,static
dhcp-option=option:router
dhcp-option=121,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=249,192.168.70.0/24,192.168.99.254,192.168.75.0/24,192.168.99.254,10.0.0.0/24,192.168.99.254
dhcp-option=vendor:MSFT,2,1i
[root@vpn ~]#
===

Ну и напоследок, как оно выглядит по логам сервера (взял первую попавшуюся сессию, но потом для tcpdump'ов пришлось подымать свою):
===
Apr 24 12:46:44 vpn accel-pppd: ppp0:: connect: ppp0 <--> pptp(121.201.149.246)
Apr 24 12:46:48 vpn accel-pppd: ppp0:ariadna: ariadna: authentication successed
Apr 24 12:46:49 vpn accel-pppd: ppp0:ariadna: IPV6CP: discarding packet
Apr 24 12:46:52 vpn dnsmasq-dhcp[29573]: DHCPINFORM(ppp0) 192.168.99.145 00:00:00:01:00:00
Apr 24 12:46:52 vpn dnsmasq-dhcp[29573]: DHCPACK(ppp0) 192.168.99.145 00:00:00:01:00:00
===

и как оно выглядит со стороны сервера под tcpdump:
===

[root@vpn ~]# tcpdump -nn -i any port 67 or port 68 or port 1723 or proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:46:58.948885 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1a:64:20:3a:e2, length 278
19:47:02.367113 IP 124.185.115.30.1043 > 192.168.75.81.1723: Flags [S], seq 2289777816, win 64240, options [mss 1460,nop,nop,sackOK], length 0
19:47:02.367200 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [S.], seq 2009373118, ack 2289777817, win 14600, options [mss 1460,nop,nop,sackOK], length 0
19:47:02.384393 IP 124.185.115.30.1043 > 192.168.75.81.1723: Flags [P.], seq 1:157, ack 1, win 64240, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) HOSTNAME() VENDOR(Microsoft Windows NT)
19:47:02.384446 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [.], ack 157, win 15544, length 0
19:47:02.384694 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [P.], seq 1:157, ack 157, win 15544, length 156: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
19:47:02.396551 IP 124.185.115.30.1043 > 192.168.75.81.1723: Flags [P.], seq 157:325, ack 157, win 64084, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(1043) CALL_SER_NUM(8705) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
19:47:02.396710 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [P.], seq 157:189, ack 325, win 16616, length 32: pptp CTRL_MSGTYPE=OCRP CALL_ID(36) PEER_CALL_ID(1043) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0) PHY_CHAN_ID(0)
19:47:02.397171 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 1, length 35: LCP, Conf-Request (0x01), id 1, length 21
19:47:02.415255 IP 124.185.115.30.1043 > 192.168.75.81.1723: Flags [P.], seq 325:349, ack 189, win 64052, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(36) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
19:47:02.422925 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
19:47:02.454492 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [.], ack 349, win 16616, length 0
19:47:04.617621 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23
19:47:04.617762 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 2, ack 1, length 31: LCP, Conf-Reject (0x04), id 1, length 13
19:47:04.739135 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 2, ack 2, length 34: LCP, Conf-Request (0x01), id 2, length 16
19:47:04.739192 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 3, ack 2, length 34: LCP, Conf-Ack (0x02), id 2, length 16
19:47:05.397343 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 4, length 35: LCP, Conf-Request (0x01), id 1, length 21
19:47:05.429753 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 3, ack 4, length 39: LCP, Conf-Ack (0x02), id 1, length 21
19:47:05.429915 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 5, ack 3, length 41: CHAP, Challenge (0x01), id 1, Value e93c80f0954a4b880f0b117bc8558d82, Name
19:47:05.430662 IP 124.185.115.30.1043 > 192.168.75.81.1723: Flags [P.], seq 349:373, ack 189, win 64052, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(36) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
19:47:05.430686 IP 192.168.75.81.1723 > 124.185.115.30.1043: Flags [.], ack 373, win 16616, length 0
19:47:05.431411 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 4, length 34: LCP, Ident (0x0c), id 3, length 20
19:47:05.431892 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 5, length 40: LCP, Ident (0x0c), id 4, length 26
19:47:05.443616 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 6, ack 5, length 80: CHAP, Response (0x02), id 1, Value b3158deadbeefdeadbeefdeadadfb6d80000000000000000125efeadeadbeefdeadbeefdeadbeefdeadbeef6c6a377b100, Name galaxy
19:47:05.444028 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 6, ack 6, length 93: CHAP, Success (0x03), id 1, Msg S=0673ADEADBEEFDEADBEEFDEADBEED679400BED7A M=Authentication successed
19:47:05.444108 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 7, length 26: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 12
19:47:05.444142 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 8, length 26: IPCP, Conf-Request (0x01), id 1, length 12
19:47:05.459052 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 7, ack 7, length 30: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 5, length 12
19:47:05.459148 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 9, ack 7, length 30: unknown ctrl-proto (0x80fd), Conf-Nack (0x03), id 5, length 12
19:47:05.459856 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 8, length 50: IPCP, Conf-Request (0x01), id 6, length 36
19:47:05.459917 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 10, ack 8, length 36: IPCP, Conf-Reject (0x04), id 6, length 18
19:47:05.460630 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 9, length 26: IPCP, Conf-Ack (0x02), id 1, length 12
19:47:05.461744 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 10, length 26: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 1, length 12
19:47:05.469229 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 11, ack 9, length 30: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 7, length 12
19:47:05.469319 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 11, ack 11, length 30: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 7, length 12
19:47:05.471197 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 12, ack 10, length 42: IPCP, Conf-Request (0x01), id 8, length 24
19:47:05.471257 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 12, ack 12, length 42: IPCP, Conf-Nack (0x03), id 8, length 24
19:47:05.483238 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 13, ack 12, length 42: IPCP, Conf-Request (0x01), id 9, length 24
19:47:05.483405 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 13, ack 13, length 42: IPCP, Conf-Ack (0x02), id 9, length 24
19:47:05.553417 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 14, length 60: compressed PPP data
19:47:05.650250 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 15, length 348: compressed PPP data
19:47:05.650284 IP 192.168.99.151.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 300
19:47:05.650510 IP 192.168.99.254.67 > 192.168.99.151.68: BOOTP/DHCP, Reply, length 305
19:47:05.650532 IP 192.168.75.81 > 124.185.115.30: GREv1, call 1043, seq 14, ack 15, length 357: compressed PPP data
19:47:06.494779 IP 124.185.115.30 > 192.168.75.81: GREv1, call 36, seq 16, length 60: compressed PPP data
^C
45 packets captured
45 packets received by filter
0 packets dropped by kernel
[root@vpn ~]#
===

и наконец (я инициировал соедиение еще раз, чтобы поймать только DHCP) самое вкусное:
===

[root@vpn ~]# tcpdump -nnv -i any port 67 or port 68
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:54:46.715522 IP (tos 0x0, ttl 128, id 5523, offset 0, flags [none], proto UDP (17), length 328)
    192.168.99.153.68 > 255.255.255.255.67: BOOTP/DHCP, Request, length 300, htype 8, hlen 6, xid 0xa27cfc5f, secs 1536, Flags [none]
      Client-IP 192.168.99.153
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Inform
        Client-ID Option 61, length 7: hardware-type 8, 00:53:45:00:00:00
        Hostname Option 12, length 8: "intruder"
        Vendor-Class Option 60, length 8: "MSFT 5.0"
        Parameter-Request Option 55, length 6:
          Domain-Name-Server, Netbios-Name-Server, Vendor-Option, Subnet-Mask
          Classless-Static-Route-Microsoft, Domain-Name
        Vendor-Option Option 43, length 3: 220.1.0
19:54:46.716113 IP (tos 0x0, ttl 64, id 10142, offset 0, flags [none], proto UDP (17), length 333)
    192.168.99.254.67 > 192.168.99.153.68: BOOTP/DHCP, Reply, length 305, htype 8, hlen 6, xid 0xa27cfc5f, secs 1536, Flags [none]
      Client-IP 192.168.99.153
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.99.254
        Domain-Name Option 15, length 18: "vpn.server.tld"
        Classless-Static-Route-Microsoft Option 249, length 24: (192.168.70.0/24:192.168.99.254),(192.168.75.0/24:192.168.99.254),(10.0.0.0/24:192.168.99.254)
        Vendor-Option Option 43, length 7: 2.4.0.0.0.1.255
19:54:47.325798 IP (tos 0x0, ttl 128, id 50260, offset 0, flags [DF], proto UDP (17), length 306)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1a:64:20:3a:c1, length 278, xid 0x64203adb, Flags [Broadcast]
      Client-Ethernet-Address 00:1a:64:20:3a:c1
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Lease-Time Option 51, length 4: 4294967295
        Hostname Option 12, length 8: "64203AC1"
        Parameter-Request Option 55, length 3:
          Subnet-Mask, Default-Gateway, Domain-Name-Server
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
[root@vpn ~]#
===

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

С option 121 и option 249 - это работает как минимум на Win XP и выше, Mac OS X 10.7 и выше (ниже у нас тут просто нет), на всякий раутерах с поддержкой PPTP (типа Cisco, DLink, Netgear, etc.).

Признаем, что оно работает? :)  Или все еще "никак нельзя"?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от skeletor (ok) on 24-Апр-12, 14:22 
Вы оказались правы :) Ещё вычитал, что винда иногда не понимает опцию 121, поэтому стоит применять 249. В остальном - очень хорошо. Признаюсь, не знал о таких возможностях pptp.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "PPTP и передача роутинга windowns клиенту"  +2 +/–
Сообщение от GalaxyMaster email on 24-Апр-12, 14:46 
> Вы оказались правы :) Ещё вычитал, что винда иногда не понимает опцию
> 121, поэтому стоит применять 249. В остальном - очень хорошо. Признаюсь,
> не знал о таких возможностях pptp.

Я еще в первом своем посте указал, что MS изобрел велосипед и _вместо_ 121 исрользует 249, другими словами Windows _никогда_ не понимает 121, зато DLink'и понимают только 121 (если мне память не изменяет) :).  OK, рад, что убедил :)) Удачных настроек PPTP в будущем (и если будете пользоваться accel-ppp - поддержите соотечественика материально :) - пакет того стоит (несмотря на отсутствие нормальной документации).

P.S. Я никак не связан с проектом accel-ppp, просто на фоне всех остальных решений (похожих) - он супер!


Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от Dmitry (??) on 12-Фев-13, 14:48 
> Вы оказались правы :) Ещё вычитал, что винда иногда не понимает опцию
> 121, поэтому стоит применять 249. В остальном - очень хорошо. Признаюсь,
> не знал о таких возможностях pptp.

Он оказался не прав.

Где таблица route print клиента после авторизации?

Apr 24 12:46:44 vpn accel-pppd: ppp0:: connect: ppp0 <--> pptp(121.201.149.246)
Apr 24 12:46:48 vpn accel-pppd: ppp0:ariadna: ariadna: authentication successed

Зачем пихать маршруты к сетям 70, 75 и 10.0.0.0 в туннель, если они и так туда по-умолчанию пойдут?

Наличие dnsmasq совершенно не нужно для того, чтобы засунуть сети внутрь туннеля.

А вот вытащить их из туннеля - другое дело.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

15. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от GalaxyMaster email on 13-Фев-13, 13:52 
>> Вы оказались правы :) Ещё вычитал, что винда иногда не понимает опцию
>> 121, поэтому стоит применять 249. В остальном - очень хорошо. Признаюсь,
>> не знал о таких возможностях pptp.
> Он оказался не прав.

Это почему же? :)  Потому что Вам просто так хочется?

> Где таблица route print клиента после авторизации?

Если бы в тот момент, когда я решил потратить на описание свое время кто-нибудь спросил, я бы предоставил.  Просто я считал, что мы не малые дети и не нужно уж совсем банальные вещи постить.  Конечно же, все маршруты выставляются клиентом, иначе бы смысла во всем этом не было бы.

> Зачем пихать маршруты к сетям 70, 75 и 10.0.0.0 в туннель, если
> они и так туда по-умолчанию пойдут?

С какой радости они туда пойдут?  VPN поднимается на клиенте без default route на этот туннель - иначе мы лишим клиента нормального доступа в инет.  Особенно это актуально, если клиент поключается сразу к нескольким VPN серверам.

> Наличие dnsmasq совершенно не нужно для того, чтобы засунуть сети внутрь туннеля.

А я и не говорил, что именно dnsmasq нужен, я сказал, что _любой_ DHCP сервер пойдет :), а вот без DHCP засунуть не получиться :)

> А вот вытащить их из туннеля - другое дело.

Общие слова какие-то :( ... О чем говорим-то?  Я предоставил конфиги работающей системы, которая сейчас крутится на десятках филлиалов и пользователи не имеют никаких проблем, когда администраторы обновляют маршруты.  Конфигурация была настроена в соответствии с сушествующими стандартами (я да же ссылки, вроде как, указывал).  Вы же просто сказали, что все плохо, но не обосновали.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от LSTemp (ok) on 14-Фев-13, 03:00 
>> Иногда так умиляют люди, которые не имея опыта (или времени почитать стандарты)
>> категорично заявляют вещи о которых понятия не имеют :))
> Так пишут люди, которые слышали звон да не знают где он :)
> Что бы разрешить спор (думаю так будет правильнее всего) приведите сюда ваши
> настройки на которых всё работает и при этом виндовый клиент при
> подключении получает нужные маршруты.
> А бросать ссылки и уходить от первоначальной темы - для этого большого
> ума не надо.
> ПС. Без приведённых практических примеров доказывать что это возможно - просто троллить.

#dhcpd --version
isc-dhcpd-4.2.4-P2

сборка из исходников.

...
###
### define options for MS and RFC3442 classlesss routes
###

option ms-classless-routes code 249 = array of unsigned integer 8;
option rfc3442-classless-routes code 121 = array of unsigned integer 8;

subnet 192.168.0.0 netmask 255.255.255.0 {
    interface eth1;

    option routers 192.168.0.1;
    option domain-name-servers 192.168.0.1;
    option ntp-servers 192.168.0.1;
    
    range 192.168.0.4 192.168.0.6;
    option subnet-mask 255.255.255.248;
    
    option ms-classless-routes          
        8,      10,             192,168,0,1,
        16,     192,168,        192,168,0,1,
        12,     172,16,         192,168,0,1,
        24,     192,168,200,    192,168,200,1;
        
    option rfc3442-classless-routes    
        8,      10,             192,168,0,1,
        16,     192,168,        192,168,0,1,
        12,     172,16,         192,168,0,1,
        24,     192,168,200,    192,168,200,1;
    
    min-lease-time 1800;
    max-lease-time 7200;
    default-lease-time 3600;
}

еще вопросы?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от TAIPHOON (ok) on 17-Окт-12, 20:01 
> OK, я знаю, что нитка старая, но она выдается в поисковиках, и
> я внесу свою маленькую лепту в облегчение страдающих описанной проблемой:

Спасибо:).
Реализовал у себя аналогичную отправку маршрутов на D-Link DFL-260e.
Но вот проблема: Windows 7 не желает применять полученное по DHCP.
На данный момент по DHCP внутри PPTP отправляю:
DNS сервер
DNS суффикс
Опции 121 и 249
WinXP прекрасно всё это получает и применяет. Win7 получает (снифил трафик), но ни чего не применяет. UAC отключал. Что может мешать применению DHCP опций?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от skeletor email(ok) on 18-Окт-12, 12:57 
>[оверквотинг удален]
> Спасибо:).
> Реализовал у себя аналогичную отправку маршрутов на D-Link DFL-260e.
> Но вот проблема: Windows 7 не желает применять полученное по DHCP.
> На данный момент по DHCP внутри PPTP отправляю:
> DNS сервер
> DNS суффикс
> Опции 121 и 249
> WinXP прекрасно всё это получает и применяет. Win7 получает (снифил трафик), но
> ни чего не применяет. UAC отключал. Что может мешать применению DHCP
> опций?

Может стоит запускать от имени администратора? Не раз сталкивался с похожим, даже при отключении UAC.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от TAIPHOON (ok) on 19-Окт-12, 11:03 
> Может стоит запускать от имени администратора? Не раз сталкивался с похожим, даже
> при отключении UAC.

Пробовал - не помогает. Ещё заметил, что ipconfig /all говорит, "DHCP: Нет".

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от GalaxyMaster email(ok) on 13-Фев-13, 14:25 
>> Может стоит запускать от имени администратора? Не раз сталкивался с похожим, даже
>> при отключении UAC.
> Пробовал - не помогает. Ещё заметил, что ipconfig /all говорит, "DHCP: Нет".

Администратор не нужен.  Это нормально, что ipconfig /all говорит "DHCP: No" на этот линк - у меня тоже самое.

Проверьте, что в настройках Вашего соединения -> Networking -> Internet Protocol Version 4 (TCP/IPv4) -> Properties -> Advanced -> IP Settings: сняты галочки с 'Use default gateway on remote network' и 'Disable class based route addition'.  Если стоит первая - маршруты игнорируются, так как это и так маршрут по умолчанию, если стоит вторая, то маршруты игнорируются так как Вы сами сказали их игнорировать :).

Прилагаю немного дампов для того, чтобы некоторые люди не спрашивали больше про ROUTE PRINT и подобное:

C:\Users\galaxy>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                          State
============================= ==================================== ========
SeShutdownPrivilege           Shut down the system                 Disabled
SeChangeNotifyPrivilege       Bypass traverse checking             Enabled
SeUndockPrivilege             Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set       Disabled
SeTimeZonePrivilege           Change the time zone                 Disabled

C:\Users\galaxy>

Только что подключился с Win7 через L2TP (так как в данном месте NAT и PPTP маскарада нет :( ):

таблица до подключения:
===
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\galaxy>route print
===========================================================================
Interface List
11...08 00 27 e0 85 65 ......Intel(R) PRO/1000 MT Desktop Adapter
  1...........................Software Loopback Interface 1
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
14...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.2.2        10.0.2.15     10
         10.0.2.0    255.255.255.0         On-link         10.0.2.15    266
        10.0.2.15  255.255.255.255         On-link         10.0.2.15    266
       10.0.2.255  255.255.255.255         On-link         10.0.2.15    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
   203.83.193.193  255.255.255.255         10.0.2.2        10.0.2.15     11
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         10.0.2.15    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link         10.0.2.15    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination      Gateway
13     58 ::/0                     On-link
  1    306 ::1/128                  On-link
13     58 2001::/32                On-link
13    306 2001:0:9d38:953c:105b:331c:f5ff:fdf0/128
                                    On-link
11    266 fe80::/64                On-link
13    306 fe80::/64                On-link
13    306 fe80::105b:331c:f5ff:fdf0/128
                                    On-link
11    266 fe80::e013:1a5d:57c:45e5/128
                                    On-link
  1    306 ff00::/8                 On-link
13    306 ff00::/8                 On-link
11    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Таблица после подключения:

C:\Users\galaxy>route print
===========================================================================
Interface List
20...........................VPN Connection
11...08 00 27 e0 85 65 ......Intel(R) PRO/1000 MT Desktop Adapter
  1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
14...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.2.2        10.0.2.15     10
         10.0.0.0    255.255.255.0         On-link    192.168.82.156     11
       10.0.0.255  255.255.255.255         On-link    192.168.82.156    266
         10.0.2.0    255.255.255.0         On-link         10.0.2.15    266
        10.0.2.15  255.255.255.255         On-link         10.0.2.15    266
       10.0.2.255  255.255.255.255         On-link         10.0.2.15    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
     192.168.70.0    255.255.255.0         On-link    192.168.82.156     11
   192.168.70.255  255.255.255.255         On-link    192.168.82.156    266
     192.168.73.0    255.255.255.0         On-link    192.168.82.156     11
   192.168.73.255  255.255.255.255         On-link    192.168.82.156    266
     192.168.82.0    255.255.255.0   192.168.82.254   192.168.82.156     11
   192.168.82.156  255.255.255.255         On-link    192.168.82.156    266
   203.83.193.193  255.255.255.255         10.0.2.2        10.0.2.15     11
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         10.0.2.15    266
        224.0.0.0        240.0.0.0         On-link    192.168.82.156    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link         10.0.2.15    266
  255.255.255.255  255.255.255.255         On-link    192.168.82.156    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination      Gateway
13     58 ::/0                     On-link
  1    306 ::1/128                  On-link
13     58 2001::/32                On-link
13    306 2001:0:9d38:6ab8:58:2564:f5ff:fdf0/128
                                    On-link
11    266 fe80::/64                On-link
13    306 fe80::/64                On-link
13    306 fe80::58:2564:f5ff:fdf0/128
                                    On-link
11    266 fe80::e013:1a5d:57c:45e5/128
                                    On-link
  1    306 ff00::/8                 On-link
13    306 ff00::/8                 On-link
11    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\Users\galaxy>


Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от LSTemp (ok) on 14-Фев-13, 02:54 
> Передать роутинг посредством pptp - нельзя. Это может только openvpn.

зато можно ч/з dhcp  - это вроде в теме вопроса, раз там все "на автомате"


Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от Moomintroll (ok) on 28-Сен-11, 10:34 
> Вообще как-то можно при подключении PPTP к серверу, раздать клиенту только один
> нужный маршрут, как это делается на openvpn, напр., push "route 10.1.2.30
> 255.255.255.255"?

Нельзя. В PPTP/PPP не предусмотрена передача маршрутов.

Для виндовых клиентов можно использовать CMAK - Connection Manager Administration Kit. Есть в комплекте всех серверных Windows. На выходе CMAK получается некий exe-шник, который при запуске(установке) создаёт соединение с заданными параметрами полностью готовое к применению. Среди прочих параметров (как, например, адрес VPN-сервера) есть возможность задать практически произвольную маршрутизацию. Для этого создаётся текстовый файл с правилами, который и отдаётся CMAK'у. В общем случае будет примерно так:


ADD 192.168.0.0 MASK 255.255.255.0 default METRIC default IF default
REMOVE_GATEWAY

На самом деле CMAK может ещё много, но это уже в двух словах не описать...

Читайте маны - они рулёз! (c)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от секрет_полишинеля on 28-Сен-11, 10:37 
>[оверквотинг удален]
> ему доступен, как бы все ок. НО, у клиента по умолчанию
> роутинг на винде становится через IP адрес присвоенного PPTP интерфейсу. Соответственно,
> если клиент подключается через PPTP для получения доступа только к 1
> сервису, у него перестает работать все остальное.
> В настройках windows pptp можно убрать флажок - не использовать рутинг по
> умолчанию. Тогда Роутинг клиента не меняется, но для для доступа в
> нашу подсеть, надо выполнить команду route add. Короче не вариант.
> Вообще как-то можно при подключении PPTP к серверу, раздать клиенту только один
> нужный маршрут, как это делается на openvpn, напр., push "route 10.1.2.30
> 255.255.255.255"?

Открою вам страшную тайну (только тс-с-с! ниому ни слова, а то сейчас коршуны налетят и заклюют!) - МОЖНО! (шепотом)
)))
Вы делаете все правильно, а вашу команду для винды, где вы добавляете нужный вам маршрут (route add) закиньте в cmd или bat и в автозагрузку. Или задать с ключиком -p
route /? попробуйте.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от vovan_sh (ok) on 28-Сен-11, 14:03 
>[оверквотинг удален]
>> Вообще как-то можно при подключении PPTP к серверу, раздать клиенту только один
>> нужный маршрут, как это делается на openvpn, напр., push "route 10.1.2.30
>> 255.255.255.255"?
> Открою вам страшную тайну (только тс-с-с! ниому ни слова, а то сейчас
> коршуны налетят и заклюют!) - МОЖНО! (шепотом)
> )))
> Вы делаете все правильно, а вашу команду для винды, где вы добавляете
> нужный вам маршрут (route add) закиньте в cmd или bat и
> в автозагрузку. Или задать с ключиком -p
> route /? попробуйте.

коллега, не разделяю ваш сарказм, поверьте я знаю про ключик -p, но хотелось бы сделать все красиво без лишних телодвижений для клиента, в автозагрузке указывать route add можно, но если соединение pptp установится позже автозагрузки, то роут просто выдаст ошибку добавления несуществующего шлюза, подозреваю, что с ключем -p при загрузке винды произойдет тоже самое. Плюс к этому, адреса клиенту раздаются динамически, а соответственно шлюз будет всегда разным.

В общем, мой вывод такой: клиентам раздавать статику, а для маршрутизации пользоваться либо СМАК со статич. роутом, либо службой маршрутизации винды (но только для серверных систем), клиентам с XP облом.

Спасибо

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

19. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от ZombiePm on 19-Май-16, 11:33 
>[оверквотинг удален]
>> Вообще как-то можно при подключении PPTP к серверу, раздать клиенту только один
>> нужный маршрут, как это делается на openvpn, напр., push "route 10.1.2.30
>> 255.255.255.255"?
> Открою вам страшную тайну (только тс-с-с! ниому ни слова, а то сейчас
> коршуны налетят и заклюют!) - МОЖНО! (шепотом)
> )))
> Вы делаете все правильно, а вашу команду для винды, где вы добавляете
> нужный вам маршрут (route add) закиньте в cmd или bat и
> в автозагрузку. Или задать с ключиком -p
> route /? попробуйте.

А если нет доступа к настройке клиента ?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

20. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от Шел тут on 23-Май-16, 13:35 

> А если нет доступа к настройке клиента ?

Чтобы использовать дырявый PPTP в 2016 нужно быть клиническим идиотом с точки зрения информационной безопасности.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от galaxy (??) on 25-Май-16, 12:05 
> Чтобы использовать дырявый PPTP в 2016 нужно быть клиническим идиотом с точки
> зрения информационной безопасности.

Это безосновательное оскорбление довольно большого числа людей, которым необходимо использовать данный вид VPN.  Да, в PPP протоколе есть уязвимости, но также они закрываются правильной конфигурацией данного протокола.  Так что уровень риска падает до приемлемого.

Чтобы не быть голословным, давайте я Вам дам адрес VPN сервера работающего по PPTP, а вы мне покажите, что он дырявый, послав хотя бы один пакет внутрь сети? :)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от zanswer on 30-Июн-16, 06:21 
>> Чтобы использовать дырявый PPTP в 2016 нужно быть клиническим идиотом с точки
>> зрения информационной безопасности.
> Это безосновательное оскорбление довольно большого числа людей, которым необходимо использовать
> данный вид VPN.  Да, в PPP протоколе есть уязвимости, но
> также они закрываются правильной конфигурацией данного протокола.  Так что уровень
> риска падает до приемлемого.
> Чтобы не быть голословным, давайте я Вам дам адрес VPN сервера работающего
> по PPTP, а вы мне покажите, что он дырявый, послав хотя
> бы один пакет внутрь сети? :)

Эм, а какие уязвимости есть в PPP протоколе? Или вы про аутентификацию?

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

4. "PPTP и передача роутинга windowns клиенту"  +/–
Сообщение от guest email(??) on 28-Сен-11, 11:07 
> В настройках windows pptp можно убрать флажок - не использовать рутинг по
> умолчанию. Тогда Роутинг клиента не меняется, но для для доступа в
> нашу подсеть, надо выполнить команду route add. Короче не вариант.

Можно включить proxyarp и поправить маску set ifaddr 192.168.99.1 192.168.99.10-192.168.99.200 255.255.255.0
тогда у клиента будет роут на 192.168.99/24

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру