[НЕ РЕШАЕМО] pptp сервер не "видит" собственных пиров

Да, я наверное действительно слишком упростил схему :) Опишу всю схему более детально, однако, не подумайте ничего плохого, но из соображений приватности (т.к. это хозяйство не совсем мое :) ) за место реальных ip буду использовать "фэйк", думаю это не сыграет большой роли?
Как я уже описывал, есть 2 сети: одна служебная, содержит pptp сервер, dns сервер, bgp маршрутизатор, все хосты в ней имею адреса 172.16.0.0/20. PPTP сервер действительно является маршрутизатором между клиентской и служебной сетями и имеет 2 интерфейса: один с адресом 172.16.15.15 - смотрит в служебную, второй - 10.10.15.15 - смотрит соответственно в клиентскую; вторая сетка - клиентская, в ней все клиенты имеют адреса типа 10.10.0.0/20. Хоть к делу это особого отношения не имеет, но на всякий пожарный скажу, что клиентская сеть делится на сегменты класса C, каждый сегмент "бегает" по отдельной физике и коммутируется все это хозяйство между собой свичем 3-го уровня Dlink DES 3828, в итоге получаются сети типа 10.10.х.0/24, всего 15 сетей. Интерфейсы свича здесь имеют адреса вида 10.10.х.1 в каждой сети К интерфейсу свича 10.10.15.1 как раз и подключен наш pptp сервер, все клиенты при подключении стучатся на адрес 10.10.15.15 соответственно. Клиент, устанавливающий соединение, получает адрес типа 172.16.xxx.ххх/32 (сервер также становится для них маршрутизатором) и тем самым общается со служебными машинами - они начинают "видеть" клиента за счет использования в опции proxyarp. Клиент действительно выходит в служебную сеть при помощи ip_forward, но мимо pptp трафик идти не может - служебные машины "не знают" подсети 10.10.0.0/20 + форвардинг таких ip запрещен файерволом на pptp сервере. Саму клиентскую сеть (по локальным ip) видно как и положено - только с pptp сервера а с остальных служебных машин не видно. А вот по адресам, получаемым при установке соединения клиента прекрасно видно со всех служебных машин, кроме самого pptp сервера. Парадокс правда? :) В файле pptpd.conf записаны такие строки:

option /etc/ppp/options.pptpd
logwtmp
connections 2048
listen 10.10.15.15
localip 10.10.15.15
remoteip 172.16.1.2-255,172.16.2.2-255,172.16.3.2-255,172.16.4.2-255,172.16.5.2-255,172.16.6.2-255,172.16.7.2-255,
172.16.8.2-255,172.16.9.2-255,172.16.10.2-255,172.16.11.2-255,172.16.12.2-255,172.16.13.2-255,172.16.14.2-255

пул адресов записан, но он не обязателен т.к. pptp сервер всеравно получает ip через радиус, а записан он на маловероятный и, тьфу-тьфу, никогда не происходивший, но всетаки возможный случай - падение сервера билинговой системы: его состояние непрерывно мониторится и в случае его недоступности для минимизации перерывов связи pptpd сразу перезапускается без параметра auth и радиус-плугинов, тогда раздача ip происходит по порядку согласно пулам и без аутентификации. А вот по поводу примера коннекта не совсем понял что нужно, может Вы имеете в виду запись в логах?

mtu и mru стандартные для Ethernet - 1500, а proxyarp непременно нужен, т.к. без него клиенты будут видеть друг друга еще через один хоп - следующий маршрутизатор, который будет форвардить обратно на vpn сервер. Но и без него я уже пробовал, не помогает... :(

Непременно покажу все, что может быть полезным :)

vpn / # ip rule ls
RTNETLINK answers: Operation not supported
Dump terminated

vpn / # ip route list | less
default via 172.16.0.1 dev eth0
10.10.0.0/20 via 10.10.15.1 dev eth4  metric 1
10.10.15.0/24 dev eth4  proto kernel  scope link  src 10.10.15.15
172.16.0.0/20 dev eth0  proto kernel  scope link  src 172.16.15.15
... (дальше пошли клиенты) ...
172.16.0.20 dev ppp175  proto kernel  scope link  src 10.10.15.15
172.16.0.23 dev ppp93  proto kernel  scope link  src 10.10.15.15
... (около 300-400 таких записей) ...
172.16.14.36 dev ppp218  proto kernel  scope link  src 10.10.15.15
127.0.0.0/8 dev lo  scope link

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