URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 92423
[ Назад ]
Исходное сообщение
"Не работает связка MPD + NAT в FreeBSD"
Отправлено Sergey , 11-Окт-11 17:55 
Добрый день,

Есть следующая задача: получить доступ в локальную сеть предприятия через интернет используя VPN.

Исходные данные:

Сервер на базе FreeBSD 8.0-RELEASE
Смотрит наружу реальным IP адресом ххх.ххх.ххх.ххх
Смотрит внутрь локальным адресом 192.168.0.150/24
Пользователи из локальной сети ходят в интернет через NAT, http трафик заворачивается на прокси (локально)

Настройки файрвола:

allow ip from any to any via ng0
fwd 127.0.0.1,3128 tcp from 192.168.0.0/24 to any dst-port 80
divert 8668 ip from any to any via rl0
allow ip from any to any

mpd настроен след.образом:

###mpd.conf
startup:
        set console port 5005
        set console ip 127.0.0.1
        set console user admin  admin
        set console open
        set web port 5006
        set web ip 0.0.0.0
        set web user admin      qwerty
        set web open

default:
        load line

line:
        new -i ng0 line pptp
        load server-parameters

server-parameters:
        set iface enable proxy-arp
        set iface enable tcpmssfix
        set link no pap
        set link enable chap
        set link keep-alive 10 60
        set link mtu 1460
        set ipcp ranges 192.168.0.150/32 192.168.0.195/32
        set ipcp dns 192.168.0.111
        set ipcp nbns 192.168.0.111
        set bundle enable compression
        set bundle enable encryption
        set ccp yes mppc
        set ccp yes mpp-e40
        set ccp yes mpp-e128
        set ccp yes mpp-stateless

###mpd.links
pptp:
        set phys type pptp
        set pptp enable incoming
        set pptp disable originate

###mpd.secret
user   "password"

Устанавливаю VPN соединение, все проходит отлично. C VPN-клиента  пингуется 192.168.0.150. Но другие хосты сети 192.168.0.ххх я не могу пинговать.

Вот как выглядит ipconfig -all на клиенте после установки соединения:

Test - PPP адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Физический адрес. . . . . . . . . : 00-53-45-00-00-00
        Dhcp включен. . . . . . . . . . . : нет
        IP-адрес  . . . . . . . . . . . . : 192.168.0.195
        Маска подсети . . . . . . . . . . : 255.255.255.255
        Основной шлюз . . . . . . . . . . : 192.168.0.195
        DNS-серверы . . . . . . . . . . . : 192.168.0.111
        Основной WINS-сервер  . . . . . . : 192.168.0.111

Вот поднятый интерфейс на сервере:

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1394
        inet 192.168.0.150 --> 192.168.0.195 netmask 0xffffffff

Все вроде в порядке, но не работает доступ дальше сервера (могу ходить в инет через локальную проксю например). Но доступа к другим компам сети 192.168.0.ххх нет. =( Где я ошибся?

Есть две версии: мешает NAT или проблема маршрутизации. Голову уже сломал =(

Спасибо.

Содержание
Сообщения в этом обсуждении
"Не работает связка MPD + NAT в FreeBSD"
Отправлено de_mone , 11-Окт-11 18:06 
1. Провертье, чтобы удаленные машины, которые подключаются по VPN не имели серых адресов подсети .0.0/24 (иначе при поднятии VPN откуда машина будет знать, в какой интерфейс ей кидать пакеты - в локальный или VPN)
2. Не увидел правил на фаерволе, разрешающее проход GRE.


"Не работает связка MPD + NAT в FreeBSD"
Отправлено Sergey , 11-Окт-11 18:19 
> 1. Провертье, чтобы удаленные машины, которые подключаются по VPN не имели серых
> адресов подсети .0.0/24 (иначе при поднятии VPN откуда машина будет знать,
> в какой интерфейс ей кидать пакеты - в локальный или VPN)
> 2. Не увидел правил на фаерволе, разрешающее проход GRE.

По п.1 При поднятии VPN-соединения автоматически добавляется маршрут 0.0.0.0 0.0.0.0 на шлюз 192.168.0.195 перекрывающий по метрике дефолтный для удаленного компа.

===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0    192.168.0.195   192.168.0.195       1
          0.0.0.0          0.0.0.0  192.168.150.252  192.168.150.207      21

Вот трассер с удаленной машины при поднятом VPN:

C:\>tracert 192.168.0.2

Трассировка маршрута к 192.168.0.2 с максимальным числом прыжков 30

  1   103 ms    88 ms   134 ms  192.168.0.150
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     *        *        *     Превышен интервал ожидания для запроса.
  5     *        *        *     Превышен интервал ожидания для запроса.
  6     *        *        *     Превышен интервал ожидания для запроса.
  7     *        *        *     Превышен интервал ожидания для запроса.
  8     *        *        *     Превышен интервал ожидания для запроса.

по п.2 allow gre any to any добавлял. Не помогает. Само VPN соединение устанавливается нормально, трафик gre проходит по финальному правилу allow any to any.
Тут что-то другое...

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 11-Окт-11 18:22 
>[оверквотинг удален]
>   7     *    
>    *        
> *     Превышен интервал ожидания для запроса.
>   8     *    
>    *        
> *     Превышен интервал ожидания для запроса.
> по п.2 allow gre any to any добавлял. Не помогает. Само VPN
> соединение устанавливается нормально, трафик gre проходит по финальному правилу allow
> any to any.
> Тут что-то другое...

выходит, что сервер VPN (он же роутер) имеет на одном интерфейсе сеть 192.168.0.0/24 и на другом интерфейсе (ngX) ту же подсеть.... имхо не верно это. лучше удалённым клиентам выдавать другую подсеть.

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Sergey , 11-Окт-11 18:27 
> выходит, что сервер VPN (он же роутер) имеет на одном интерфейсе сеть
> 192.168.0.0/24 и на другом интерфейсе (ngX) ту же подсеть.... имхо не
> верно это. лучше удалённым клиентам выдавать другую подсеть.

Пробовал по всякому. Выдавал сетку 10.10.10.ххх.
Сейчас попробую еще раз.
Мне вот что интересно, если клиент будет получать адрес 10.10.10.ххх, то его запросы к 192.168.0.2 будут приходить как от 10.10.10.ххх или 192.168.0.150?

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 11-Окт-11 18:32 
>> выходит, что сервер VPN (он же роутер) имеет на одном интерфейсе сеть
>> 192.168.0.0/24 и на другом интерфейсе (ngX) ту же подсеть.... имхо не
>> верно это. лучше удалённым клиентам выдавать другую подсеть.
> Пробовал по всякому. Выдавал сетку 10.10.10.ххх.
> Сейчас попробую еще раз.
> Мне вот что интересно, если клиент будет получать адрес 10.10.10.ххх, то его
> запросы к 192.168.0.2 будут приходить как от 10.10.10.ххх или 192.168.0.150?

если между клиентом и 192.168.0.2 нет NAT, то с какой радости "его запросы к 192.168.0.2 будут приходить как от 10.10.10.ххх или 192.168.0.150?"?

если давать клиенту другую подсеть, то видимо надо указать на клиенте что подсеть 192.168.0.0/24 находится за <шлюз по дефолту после поднятия VPN>
проблема заключается в том, что винда н епринимает от pptp-сервера под юниксом некоторые параметры при подключении, например указания маршрутов. (когда-то долго это ковырял и плюнул в итоге), следовательно надо на клиента поднять VPN и прописать маршрут с -p (т.е. постоянный), но тогда и галочку в настройках ВПН на клиенте, про маршрут по дефолту в удалённую сеть ставить не надо.
т.е. написать батник и раздать удалённым клиентам ... действия на клиенте такие:
1. настроить ВПН и подключиться
2. выполнить батник
всё ... дальше должно всё сростаться и после ребута клиента

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Sergey , 11-Окт-11 18:52 
>[оверквотинг удален]
> проблема заключается в том, что винда н епринимает от pptp-сервера под юниксом
> некоторые параметры при подключении, например указания маршрутов. (когда-то долго это
> ковырял и плюнул в итоге), следовательно надо на клиента поднять VPN
> и прописать маршрут с -p (т.е. постоянный), но тогда и галочку
> в настройках ВПН на клиенте, про маршрут по дефолту в удалённую
> сеть ставить не надо.
> т.е. написать батник и раздать удалённым клиентам ... действия на клиенте такие:
> 1. настроить ВПН и подключиться
> 2. выполнить батник
> всё ... дальше должно всё сростаться и после ребута клиента

Trafshow показывает, что icmp пакеты проходят через ng0, попадают в re0 (внутренний интерфейс) а вот пингуемый 192.168.0.111 не отвечает. Т.е. я на trafshow не вижу ответа от 192.168.0.111.

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Sergey , 11-Окт-11 19:04 
Разобрался что к чему.
Все работает нормально, когда меняю настройку

set ipcp ranges 192.168.0.150/32 192.168.0.195/32

на

set ipcp ranges 10.10.10.1/32 10.10.10.2/32

Все нормально пингуется, но только те хосты, для которых default gateway является машина под FreeBSD. Но сервера к которым нужен доступ не имеют шлюза по умолчанию.
Решением было бы прописать там маршрут ручками, но хочется сделать VPN не зависимый от маршрутов, т.е. попадать в сеть с адресацией самой сети, т.е. 192.168.0.ххх

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 11-Окт-11 22:48 
>[оверквотинг удален]
> Все работает нормально, когда меняю настройку
>  set ipcp ranges 192.168.0.150/32 192.168.0.195/32
> на
>  set ipcp ranges 10.10.10.1/32 10.10.10.2/32
> Все нормально пингуется, но только те хосты, для которых default gateway является
> машина под FreeBSD. Но сервера к которым нужен доступ не имеют
> шлюза по умолчанию.
> Решением было бы прописать там маршрут ручками, но хочется сделать VPN не
> зависимый от маршрутов, т.е. попадать в сеть с адресацией самой сети,
> т.е. 192.168.0.ххх

а какой высокий смысл в том, что на серверах нет шлюза по дефолту?
т.е. подразумевается, что серверы живут в своей подсети и им не важно что где-то есть другие подсети? в этом смысл?
ну что ж ... круто! ;) из разряда "что б не подхватить вирус надо выдернуть кабель" :)
Думаю надо пересмотреть подходы к построению сетей и сделать таки по-людски.
А-то есть разряд людей, которые сначала создают себе проблемы, а потом с доблестью их преодолевают ;)

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 11-Окт-11 18:19 
> 2. Не увидел правил на фаерволе, разрешающее проход GRE.

последним правилом стоит:
allow ip from any to any
спец. правила для GRE не нужно

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Сергей , 12-Окт-11 09:20 
Попробуйте
  set ippool add poolsat 192.168.0.начальный 192.168.0.конечный
  set ipcp ranges 192.168.0.195/24 ippool poolsat
Спать хочется... Сейчас точно не воспроизведу
"Не работает связка MPD + NAT в FreeBSD"
Отправлено andy03 , 13-Окт-11 22:23 
>[оверквотинг удален]
>         set bundle enable encryption
>         set ccp yes mppc
>         set ccp yes mpp-e40
>         set ccp yes mpp-e128
>         set ccp yes mpp-stateless
> ###mpd.links
> pptp:
>         set phys type pptp
>         set pptp enable incoming
>         set pptp disable originate

у меня еще добавлено в mpd.conf
set iface up-script /usr/local/etc/mpd4/routes-up.sh
set iface down-script /usr/local/etc/mpd4/routes-down.sh

#cat /usr/local/etc/mpd4/routes-up.sh
if [ $4 = "10.0.0.240" ]
then
  /sbin/route add 192.168.166.0/24 10.0.0.240
fi

#cat /usr/local/etc/mpd4/routes-down.sh
if [ $4 = "10.0.0.240" ]
then
  /sbin/route delete 192.168.166.0/24 10.0.0.240
fi

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

ну и плюс то, что написал Grey - правда

на счет GRE, если подключение есть, то GRE работает, иначе была бы ошибка у клиента

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 13-Окт-11 23:17 
>[оверквотинг удален]
> fi
> #cat /usr/local/etc/mpd4/routes-down.sh
> if [ $4 = "10.0.0.240" ]
> then
>   /sbin/route delete 192.168.166.0/24 10.0.0.240
> fi
> тогда при подключении клиента впн-концентратор будет знать какая подсеть находится за клиентом...
> а на клиентах, естественно нужен маршрут к сети за впн-концентратором
> а к машинам без дефолтного шлюза не достучатся в принципе из другой
> подсети.

ВПН сервер и так знает где находится подсеть в которой находится удалённый клиент, имхо маршрут на нём (ВПН-сервере) поднимать не надо.

"Не работает связка MPD + NAT в FreeBSD"
Отправлено andy03 , 13-Окт-11 23:32 
>[оверквотинг удален]
>> if [ $4 = "10.0.0.240" ]
>> then
>>   /sbin/route delete 192.168.166.0/24 10.0.0.240
>> fi
>> тогда при подключении клиента впн-концентратор будет знать какая подсеть находится за клиентом...
>> а на клиентах, естественно нужен маршрут к сети за впн-концентратором
>> а к машинам без дефолтного шлюза не достучатся в принципе из другой
>> подсети.
> ВПН сервер и так знает где находится подсеть в которой находится удалённый
> клиент, имхо маршрут на нём (ВПН-сервере) поднимать не надо.

в случае, если за клиентом другая подсеть, то надо

"Не работает связка MPD + NAT в FreeBSD"
Отправлено Grey , 13-Окт-11 23:49 
>[оверквотинг удален]
>>> then
>>>   /sbin/route delete 192.168.166.0/24 10.0.0.240
>>> fi
>>> тогда при подключении клиента впн-концентратор будет знать какая подсеть находится за клиентом...
>>> а на клиентах, естественно нужен маршрут к сети за впн-концентратором
>>> а к машинам без дефолтного шлюза не достучатся в принципе из другой
>>> подсети.
>> ВПН сервер и так знает где находится подсеть в которой находится удалённый
>> клиент, имхо маршрут на нём (ВПН-сервере) поднимать не надо.
> в случае, если за клиентом другая подсеть, то надо

случаев ещё много можно придумать, но о них в "задаче" речи нет. Надо подключить удалённого клиента(тов) но не сеть(сети)