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

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

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

работает

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

хитроспрятанные бубунты на виртуалбоксах и 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

как-то так =)

Маршруты на клиенте (после установления 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

кто такой 192.168.252.1? и маршруты dns-сервера, плиз

кто такой 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

Вот

из того что я вижу : 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 ? Вы бы пустили трассировочку-то, туда и обратно (с ВМ хитрой сети на днс, и обратно) - сразу станет видно что не так,кмк

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

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

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

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 ? а еще есть пингИ, мда..

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

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

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

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

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

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

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

Эх, ну это.. к чему все это веду..есть маршрут : 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/ и его подкаталогах есть то что создает маршрут

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

Это точно.

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

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

Щито? 0_о Поясните мысль, анонимный коллега...

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