LINUX.ORG.RU
решено ФорумAdmin

Странности с dns-запросами over pptp

 , , ,


0

1

Приветствую, уважаемые.
Давненько я не приставал к вам с глупостями.

Ситуация, значит, следующая. Есть в сети компании изолированная подсеть (в другие подсети и в интернет напрямую доступа не имеет). В ней машины на Windows, на которых стоят virtualbox. В этих virtualbox запускается виртуалка с Ubuntu, в которой поднимается pptp-сессия на сервер с pptpd (тоже с Ubuntu), находящийся внутри другой подсети, уже имеющей доступ в интернет. Через это pptp соединение пользователи имеют доступ в интернет со своих виртуалок.

Проблема в следующем. Перестали разрешаться dns-имена сквозь pptp. DNS локальный, живет в неизолированной подсети. С машин, находящихся в неизолированной подсети dns-запросы обрабатываются корректно, а сквозь pptp- нет. На pptpd сервере в options прописано

ms-dns 192.168.255.251 (DNS-сервер в неизолированной сети, работает)

при коннекте pptp-клиента он клиенту выдается.

и, ЧСХ, если клиенту (после соединения сессии) дописать в resolv.conf

nameserver 8.8.8.8

то он dns-запросы обрабатывает, правда, чрезвычайно медленно.

Вот такая, с позволения сказать, петрушка. Подскажите, куда ж копать, уважаемые.

ms-dns 192.168.255.251 DNS-сервер в неизолированной сети,

хитроспрятанные бубунты на виртуалбоксах и ms-dns видят друг друга после установления туннеля, не ? Маршруты плиз

работает

как проверяли ?)

masq ()
Ответ на: комментарий от masq

хитроспрятанные бубунты на виртуалбоксах и ms-dns видят друг друга после установления туннеля, не ? Маршруты плиз

Маршруты с сервера или с клиента?

работает

как проверяли ?)

$ nslookup

server 192.168.255.251

Default server: 192.168.255.251
Address: 192.168.255.251#53

ya.ru

Server: 192.168.255.251
Address: 192.168.255.251#53

Non-authoritative answer:
Name: ya.ru
Address: 93.158.134.3
Name: ya.ru
Address: 213.180.193.3
Name: ya.ru
Address: 213.180.204.3

как-то так =)

alexnorton ()
Ответ на: комментарий от masq

Маршруты на клиенте (после установления pptp-соединения):

# 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 50 0 0 ppp0
10.11.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth1
192.168.252.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.252.9 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.255.0 192.168.252.1 255.255.255.0 UG 0 0 0 eth0



252я подсеть - это изолированная, 255я - неизолированная. 10.11.x.x - сетевое пространство для туннелей. 192.168.252.9 - это адрес pptpd в изолированной сети, соответственно.

Маршруты на сервере:

# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.255.1 0.0.0.0 UG 0 0 0 eth0
10.11.0.100 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.11.0.101 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
10.11.0.102 0.0.0.0 255.255.255.255 UH 0 0 0 ppp2
10.11.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 ppp3
10.11.0.104 0.0.0.0 255.255.255.255 UH 0 0 0 ppp4
10.11.0.105 0.0.0.0 255.255.255.255 UH 0 0 0 ppp5
10.11.0.106 0.0.0.0 255.255.255.255 UH 0 0 0 ppp6
10.11.0.107 0.0.0.0 255.255.255.255 UH 0 0 0 ppp7
10.11.0.110 0.0.0.0 255.255.255.255 UH 0 0 0 ppp10
10.11.0.112 0.0.0.0 255.255.255.255 UH 0 0 0 ppp12
10.11.0.113 0.0.0.0 255.255.255.255 UH 0 0 0 ppp13
10.11.0.116 0.0.0.0 255.255.255.255 UH 0 0 0 ppp16
192.168.252.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

alexnorton ()
Ответ на: комментарий от masq

кто такой 192.168.252.1?

Это шлюз по умолчанию в изолированной подсети. Физически это микротик.

маршруты dns-сервера, плиз

# route -n
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.255.1 0.0.0.0 UG 0 0 0 eth0
192.168.252.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Вот

alexnorton ()
Ответ на: комментарий от alexnorton

из того что я вижу : dns-запрос с клиента 192.168.252.X на сервер 192.168.255.251 идет через этот микротик - 192.168.252.1. Он что-нибудь знает про подсеть 192.168.255.0 ? Допустим (но надо проверить) что да, тогда ответ с dns-сервера идет через шлюз 192.168.255.1, - он что-нибудь знает про 192.168.252.0 ? Вы бы пустили трассировочку-то, туда и обратно (с ВМ хитрой сети на днс, и обратно) - сразу станет видно что не так,кмк

masq ()
Ответ на: комментарий от masq

Эх, до банальной проверки я и так додумался, коллега, однако ж на виртуальных машинах все порезано предыдущим Одмином и там вырезан трасерт.
У микротика интерфейсы живут в обеих сетях и я предполагаю, что между ними маршрутизация присутствует.
Однако же, dns-запрос с клиента должен идти на в 252ю подсеть, а в 255ю, сквозь pptp-соединение. Получается, не прописывается нужный маршрут? Не подскажете, как это проверить?

alexnorton ()
Ответ на: комментарий от masq

и маршруты видимо путаются на каком-то участке, поэтому гугловый днсник оч долго возвращает. опять же - mtr/traceroute/tracepath/что сердцу ближе.

masq ()
Ответ на: комментарий от alexnorton

дык.. на клиенте же у вас :

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.255.0 192.168.252.1 255.255.255.0 UG 0 0 0 eth0

без всяких pptp, ёмоё Xd как вам проверить маршруты ? посмотреть на таблицы с помощью глаз, или используя инструменты диагностики маршрутизации. Если их украдено до вас, верните взад, - mtr/traceroute/tracepath

..предполагаю..

это зря.. проверяйте. вот с днс-сервера как трафик идет, и идет ли вообще на 192.168.252.0 ? а еще есть пингИ, мда..

masq ()
Ответ на: комментарий от masq

а точно не троллинг ? :D

Точно. Я тут всего полторы недели, но предполагаю, что предыдущий деятель был тот еще шутник...

На микротике связи между подсетями нет - как раз там реализовано разделение на изолированую/неизолированную подсеть.

посмотреть на таблицы с помощью глаз, или используя инструменты диагностики маршрутизации. Если их украдено до вас, верните взад, - mtr/traceroute/tracepath

Я не могу продиагностировать, говорю же. Виртуальные машины грузятся с единого преднастроенного образа, в нем вырезано все что можно, в том числе traceroute и tracepath. Так что про маршрут прохождения трафика я могу только гадать.

Однако, в настойках pptpd-сервера есть параметр, отвечающий за смену маршрута по умолчанию на клиенте?

alexnorton ()
Ответ на: комментарий от alexnorton

Эх, ну это.. к чему все это веду..есть маршрут : 192.168.255.0 192.168.252.1 255.255.255.0 UG 0 0 0 eth0 он есть статичный, прописан и существует до поднятия ppp-интерфейса, и после. Вы его удалите, например. и будет трафик-жирафик ходить через ppp а не етх0, к сети 192.168.255.0, гыгы.. это все в случае если на Бубунтовом pptpd все нормально, ага. Но судя по всему у вас то еще болото, уж звиняйте.

Однако, в настойках pptpd-сервера есть параметр, отвечающий за смену маршрута по умолчанию на клиенте?

Нетъ. Это на стороне pptp-клиента должно определяться какие маршруты использовать, какие создавать при появлении ppp интерфейса и т.п.

Виртуальные машины грузятся с единого преднастроенного образа

pxe-iso-boot ? ну надо этот образ расковырять, и посмотреть, что создает маршрут к 255сетке через 252.1, В /etc/network/ и его подкаталогах есть то что создает маршрут

masq ()
Ответ на: комментарий от masq

Но судя по всему у вас то еще болото, уж звиняйте.

Это точно.

Спасибо за советы. Как разберусь, отпишусь как решилась сия мистика. ;-)

alexnorton ()
Ответ на: комментарий от alexnorton

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

anonymous ()

Проблема решилась, хоть и не совсем ровно. Суть: pptp сервер авторизовывал подключающихся через AD с помощью Freeradius. AD на Samba4, работает на двух DC, но Freeradius авторизуется только на одном из них. При некоторых обстоятельствах (предположительно при сбое репликации между DC) Freeradius терял регистрацию на DC и начинал отлуплять всех подключающихся. После восстановления его работы, пользователи авторизовывались, но параметры подключени pptp-сессии получали...хм... некорректные. Явно не все, что описаны в конфигурационных файлах.
Я предположил, что виноваты настройки клиента, хранящиеся в загружаемом по сети initrd.img. Расковырять и переделать мне его не дали =))) Так что теперь будем менять все схему подключения клиентов, выведя эти виртуалки из работы.
Вопрос закрыт, всем спс за ответы.

alexnorton ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.