форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (VPN / FreeBSD)
Изначальное сообщение		[ Отслеживать ]

"Не работает связка MPD + NAT в FreeBSD"	+/–
Сообщение от Sergey (??) on 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 или проблема маршрутизации. Голову уже сломал =( Спасибо.
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

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

	2. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Sergey (??) on 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. Тут что-то другое...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Grey (ok) on 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) ту же подсеть.... имхо не верно это. лучше удалённым клиентам выдавать другую подсеть.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Sergey (??) on 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?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Grey (ok) on 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. выполнить батник всё ... дальше должно всё сростаться и после ребута клиента
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Sergey (??) on 11-Окт-11, 18:52
	>[оверквотинг удален] > проблема заключается в том, что винда н епринимает от pptp-сервера под юниксом > некоторые параметры при подключении, например указания маршрутов. (когда-то долго это > ковырял и плюнул в итоге), следовательно надо на клиента поднять VPN > и прописать маршрут с -p (т.е. постоянный), но тогда и галочку > в настройках ВПН на клиенте, про маршрут по дефолту в удалённую > сеть ставить не надо. > т.е. написать батник и раздать удалённым клиентам ... действия на клиенте такие: > 1. настроить ВПН и подключиться > 2. выполнить батник > всё ... дальше должно всё сростаться и после ребута клиента Trafshow показывает, что icmp пакеты проходят через ng0, попадают в re0 (внутренний интерфейс) а вот пингуемый 192.168.0.111 не отвечает. Т.е. я на trafshow не вижу ответа от 192.168.0.111.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Sergey (??) on 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.ххх
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Grey (ok) on 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.ххх а какой высокий смысл в том, что на серверах нет шлюза по дефолту? т.е. подразумевается, что серверы живут в своей подсети и им не важно что где-то есть другие подсети? в этом смысл? ну что ж ... круто! ;) из разряда "что б не подхватить вирус надо выдернуть кабель" :) Думаю надо пересмотреть подходы к построению сетей и сделать таки по-людски. А-то есть разряд людей, которые сначала создают себе проблемы, а потом с доблестью их преодолевают ;)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	3. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Grey (ok) on 11-Окт-11, 18:19
	> 2. Не увидел правил на фаерволе, разрешающее проход GRE. последним правилом стоит: allow ip from any to any спец. правила для GRE не нужно
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Сергей (??) on 12-Окт-11, 09:20
	Попробуйте   set ippool add poolsat 192.168.0.начальный 192.168.0.конечный   set ipcp ranges 192.168.0.195/24 ippool poolsat Спать хочется... Сейчас точно не воспроизведу
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Не работает связка MPD + NAT в FreeBSD"	+/–
Сообщение от andy03 (ok) on 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 работает, иначе была бы ошибка у клиента
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Не работает связка MPD + NAT в FreeBSD"	+/–
	Сообщение от Grey (ok) on 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 > тогда при подключении клиента впн-концентратор будет знать какая подсеть находится за клиентом... > а на клиентах, естественно нужен маршрут к сети за впн-концентратором > а к машинам без дефолтного шлюза не достучатся в принципе из другой > подсети. ВПН сервер и так знает где находится подсеть в которой находится удалённый клиент, имхо маршрут на нём (ВПН-сервере) поднимать не надо.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

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

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

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

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