Решено: pptpd сервер (выход в интернет с клиентских машин)

[newsrc]

На Slackware есть сервер pptpd к нему клиенты подключаются стандартными средствами Windows. Получают IP-адрес локальной сети сервера pptpd и, понятное дело, не могут выйти в Интернет со своего компа (всё заруливается в VPN-соединение).
Возможно ли решение сей проблемы?
Спасибо.

[alex_suse]

Видимо дефолтный шлюз не надо проталкивать клиентам с помощью pptpd, а оставить тот, который и есть.

[newsrc]

На сервере дефолтовый шлюз не указан для клиентов.
После уст. соединения в Windows машина получает IP-адрес: 192.168.1.150 в выводе route print нижней строкой появляется

Код: Выделить всё

Основной шлюз: 192.168.1.150

Как бы сам на себя что ли...

[saikov]

Так и должно быть. С машины клиента пингуется локалка?
Покажи tracert ya.ru с клиента..... У тебе первая строчка должна быть с IP vpn сервера. Ну а что бы инет был, нужно уже на впн разруливать. Например через нат гнать подсеть, которую выдает впн.

Во первых разрешить форвард

iptables -A FORWARD -s 192.168.80.0/24 -o eth0 -j ACCEPT
iptables -A FORWARD -d 192.168.80.0/24 -i eth0 -j ACCEPT

А потом нат
iptables -A POSTROUTING -s 192.168.80.0/24 -o eth0 -j MASQUERADE

192.168.80.0/24 - это подсеть, которую выдает vpn.

Код: Выделить всё

C:\Documents and Settings\Saikov>tracert 192.168.2.100

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

  1    25 ms    34 ms    12 ms  192.168.80.1
  2    53 ms    34 ms    32 ms  192.168.3.77
  3  1059 ms    30 ms    30 ms  192.168.2.100

Трассировка завершена.

192.168.80.1 - впн сервер
192.168.3.77 - шлюз
192.168.2.100 - точка назначения

[alex_suse]

Данных мало, зачем натить на сервере впн, если впн не для этого я так понял или нет? Интернет у клиентов и так есть?
Есть директива nodefaultroute, которая на клиенте не меняет дефолтный шлюз при поднятии впн.

[saikov]

Данных мало, зачем натить на сервере впн, если впн не для этого я так понял или нет? Интернет у клиентов и так есть?
Есть директива nodefaultroute, которая на клиенте не меняет дефолтный шлюз при поднятии впн.

А если впн сервер за натом? И еще вопрос.... VPN пробрасывается через инет или все в локалке крутится? Тогда тупо не менять шлюз.

[newsrc]

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

VPN-сервер находится на роутере, т.е. между лок.сетью (192.168.1.0/24) и Интернетом. Через Интернет клиент с Windows подключается к VPN-серверу и получает IP-адрес 192.168.1.150. После этого клиент может пинговать локальную сеть 192.168.1.0/24 и имееть доступ к определённым ресурсам сети (для этого есть записи в IPTABLES). После установки соединения с VPN-сервером клиент не может пользоваться СВОИМ Интернетом (видимо основной шлюз в Windows, получаемый с VPN-сервера, имеет больший приоритет).

Заруливать Интернет через VPN нет смысла. Необходимо оставить доступным Интернет клиента.

iptables -A FORWARD -s 192.168.80.0/24 -o eth0 -j ACCEPT
iptables -A FORWARD -d 192.168.80.0/24 -i eth0 -j ACCEPT

Дело не в iptables и не в NAT

Данных мало, зачем натить на сервере впн, если впн не для этого я так понял или нет? Интернет у клиентов и так есть?
Есть директива nodefaultroute, которая на клиенте не меняет дефолтный шлюз при поднятии впн.

Прописал директиву nodefaultroute в options.pptpd, не помогло. На всякий случай и в конфиг pptpd.conf -- результата тоже нет.

[sash-kan]

После установки соединения с VPN-сервером клиент не может пользоваться СВОИМ Интернетом

это проблемы клиента, а не сервера·
из эпохи доисторического материализма доходят до меня отголоски фраз вида «галочка "использовать основной шлюз в удалённой сети" должна быть снята»·
даже картинка вот завалялась:

[Ленивая Бестолочь]

это проблемы клиента, а не сервера·
из эпохи доисторического материализма доходят до меня отголоски фраз вида «галочка "использовать основной шлюз в удалённой сети" должна быть снята»·

для восстановления балланса сил, я всё же напомню, что "родная виндовая" реализация pptpd умеет на стороне сервера "не отдавать" шлюз по умолчанию. таким образом админы этих серверов избавлены от необходимости объяснять юзерам, что проблема на их стороне. это печалька, но факт.

[newsrc]

sash-kan, вот эта завалявшаяся картинки и помогла. И теперь я в предвкушении звонков и объяснений пользователям, как и где эту галочку найти в WinXP да и в Win7.
Спасибо.


Ленивая Бестолоч..., неужели эта печалька неисправима в лин-версии pptpd...

[saikov]

Печалька.. Тоже протестил параметр nodefaultroute, не работает.

[sash-kan]

И теперь я в предвкушении звонков и объяснений пользователям, как и где эту галочку найти в WinXP да и в Win7.
Спасибо.

из тех же доисторических далей долетает словечко google://cmak·
когда-то с помощью этого словечка мне лично даже удалось создать программку-автоконфигуратор·

[sash-kan]

для восстановления балланса сил, я всё же напомню, что "родная виндовая" реализация pptpd умеет на стороне сервера "не отдавать" шлюз по умолчанию.

из всё тех же далей доносится воспоминание, что данная галочка присутствует в одном из диалогов создания соединения·

[sash-kan]

Прописал директиву nodefaultroute в options.pptpd, не помогло.

да и не должно было·
*defaultroute — это параметры ppp·
к pptpd они, естественно, никакого отношения не имеют·

[newsrc]

sash-kan, спасибо за помощь ну и конечно за небольшой исторический экскурс.

[Ленивая Бестолочь]

Ленивая Бестолоч..., неужели эта печалька неисправима в лин-версии pptpd...

да вот, к сожалению, рабочего решения не видел :-(
сам всем объясняю про галочку в клиенте.

из всё тех же далей доносится воспоминание, что данная галочка присутствует в одном из диалогов создания соединения·

эм. нууу, прям не знаю... пойду посмотрю.
....
посмотрел. нет, не присутствует %)

[sash-kan]

для восстановления балланса сил, я всё же напомню, что "родная виндовая" реализация pptpd умеет на стороне сервера "не отдавать" шлюз по умолчанию. таким образом админы этих серверов избавлены от необходимости объяснять юзерам, что проблема на их стороне. это печалька, но факт.

вообще забавный миф [1]·
соединение создаётся и конфигурируется _до_ первого обмена информацией с сервером·
скорее можно поверить в псевдо-ии, заложенный в мастер создания соединения — разная логика в зависимости от того, как осуществляется доступ к серверу, через шлюз или напрямую по ethernet-у [2]·

[1] чтобы освежить память, что подобной «галочки» в настройках нет, полистал в интернетах процедуры конфигурации «маршрутизации и удалённого доступа»·
собственно, вот косвенное подтверждение отсутствия такой «галочки»: http://social.technet.microsoft.com/Forums...e-60252f6d03a3/

A better solution is to create the .pbk file from your manual VPN setup, make sure you have all the correct settings, no username/password.
Copy the file to your Netlogon share, then use GP Preferences to do a simple file deployment with an Update or Replace method.

обратите внимание, что ответ "Marked As Answer byRick TanMicrosoft Contingent Staff, Moderator"
[2] вот прямое подтверждение наличия такой логики: http://technet.microsoft.com/ru-ru/library...10).aspx#BKMK_3

Не удается добавить основной шлюз.

Причина. IP-адрес основного шлюза принадлежит другому идентификатору IP-сети, нежели тот, к которому принадлежит IP-адрес используемого компьютера.

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

Например, для компьютера с одним сетевым адаптером, имеющим IP-адрес 192.168.0.33 и маску подсети 255.255.0.0, требуется, чтобы адрес основного шлюза имел вид 192.168.y.z, поскольку идентификатор сети данного IP-интерфейса равен 192.168.0.0.

посмотрел. нет, не присутствует

значит, память моя однобока…

[Ленивая Бестолочь]

http://technet.microsoft.com/ru-ru/library...352(WS.10).aspx
там вот это:

Configuring TCP/IP Settings

Use the TCP/IP settings to change the Domain Name System (DNS) and Windows Internet Name Service (WINS) client configuration by either allowing the server to assign these addresses or manually configuring the DNS and WINS addresses for this profile. You can also choose to make this connection the default gateway for the client and to use IP header compression.

[sash-kan]

http://technet.microsoft.com/ru-ru/library...352(WS.10).aspx
там вот это:

Configuring TCP/IP Settings

Use the TCP/IP settings to change the Domain Name System (DNS) and Windows Internet Name Service (WINS) client configuration by either allowing the server to assign these addresses or manually configuring the DNS and WINS addresses for this profile. You can also choose to make this connection the default gateway for the client and to use IP header compression.

так это и есть cmak, про который я писал выше (поднимись на один уровень выше в приведённой тобою ссылке, и увидишь, про настройки чего именно речь идёт)·

ты, видимо, не углублялся в то, что cmak из себя представляет·
грубо говоря, это компилятор·
ты пишешь некий конфигурационный файл, натравливаешь на него cmak, и получаешь бинарник·
этот бинарник достаточно запустить у клиента — и будет создано сетевое соединение с теми параметрами, которые указаны в том самом конф. файле·
естественно, ты можешь указать положение любых галочек (и полей) для этого сетевого соединения (может и не всех-всех-всех, я уже не помню точно, но основных — точно [1])·

upd.
[1] что точно помню — в том файле можно задать и кучу всяких «скрытых» параметров, которые обычным порядком только через правку реестра можно изменить·

upd2. примеры таких скомпилированных бинарников можно найти по запросу google://автоконфигурация vpn
вот пример на вскидку: http://forum.ufanet.ru/showthread.php?t=237
естественно, у каждого провайдера такой бинарник будет свой персональный, со своими настройками·

[sash-kan]

а теперь в приложении к gnu-клиентам·
фактически, тот бинарник, что создаётся cmak-ом, равноценен инструкции:
1. скопируйте вот этот файл (тут ссылка) в каталог /etc/ppp/peers;
2. внутри него в двух строчках "user <логин>" и "password <пароль>" укажите свои логин и пароль;
3. ...
4. profit

[Ленивая Бестолочь]

ааа, ну тогда всё ясно. возьму на вооружение :-)