BiTel

Вопрос чисто теоретический!
Сначала описание проблемы:
Есть удалённый посёлок с клиентами , соединённый с центральным оффисом достаточно нагруженным радиолинком. На выходе из посёлка стоит vpn-сервер , управляемый bgbilling-сервером, стоящим в центральном оффисе. Т.е radius-пакеты авторизации и accounting идут по тому-же радиолинку.
Такая схема работает более-менее сносно если не использовать netflow для детализации и accounting.
Но в центральном оффисе стоят и все бесплатные локальные ресурсы для клиентов, траффик с которых в принципе не должен учитываться. Но в radius-accounting пакетах естественно считается суммарная статистика, не позволяющая поделить траффик на локальный и интернет классы на bgbilling-сервере. Пришлось на vpn-сервере ставить источник netflow и гнать 2 параллельных потока на bgbilling-сервер - на vpn и ipn коллекторы для детализации и статистики по тому-же радиоканалу, вводить услуги для разных классов траффика и т.д.
Проблема в том , что даже один netflow-поток загружает и без того загруженный радиолинк - отсюда потери пакетов netflow - и как следствие - не правельный подсчёт.
А теперь сам вопрос:
Возможно ли пропускать клиентский траффик одновременно через 2 шлюза, управляемых bgbilling-сервером: первый шлюз - удалённый vpn-сервер в посёлке, который просто служит для авторизации пользователя, а второй шлюз - ipn-типа, стоящий в центральном оффисе после сетей с бесплатными локальными ресурсами прямо на выходе в интернет-дырку провайдера? Через ipn-шлюз проходит только чистый интернет-траффик и поток netflow с него отсылается на bgbilling-сервер для подсчёта траффика и детализации без деления траффика на классы ( локального траффика уже нет в netflow-потоке).Т.е пользователи посёлка одновременно являются клиентами двух шлюзов. Наверное это можно сделать с помощью субдоговоров.Основной договор - привязан к ipn-шлюзу, а субдоговор - к vpn-шлюзу .
Если я в корне не понимаю логики субдоговоров - поправьте меня пожалуйста, но если моя идея в принципе будет работать- прошу подсказать - если какие-нибудь "подводные камни" в этой схеме, чтобы их можно было учесть перед непосредственными экспериментами?

хм, похоже данная тема ни у кого не вызывает интереса, либо решение больно нестандартное.Постараюсь поразмышлять дальше.
В BGB заведены два шлюза: vpn-типа ( freebsd mpd) и ipn-типа ( linux-tc-iptables). vpn-сервер осуществляет только одну услугу( немного фиктивную)- vpn-время.Ipn-шлюз осуществляет 2 услуги - входящий и исходящий траффики в интернет. Обчёт наработки и детализации по netflow идёт именно с него. На каждого клиента заводится 1 супердоговор ( в нём услуги ipn-шлюза) и 1 субдоговор ( в нём услуга vpn-шлюза - время) .Тарифных плана - 2. Один - для субдоговора( там считается vpn-время по 0.0 руб за мин) Другой - для супердоговора - там обсчитываются услуги ipn-шлюза в какой нибудь комбинации с добавлением абон.платы NPAY. В свойстах суб- и супер-договоров клиенту присваивается всегда один и тот же ип: выдаваемый vpn-сервером и пропускаемый фильтрами manad-a ipn шлюзом.Естественно vpn-шлюз не делает nat для виртуальных клиентских ип а пропускает их прямо на вход ipn-шлюза, где они проходят через manad и NAT-ятся в выходящий ип.
Ясно , что кол-во лицензий ipn равно кол-ву лицензий vpn и равно кол-ву клиентов. Вопрос- При такой схеме при отрицательном балансе клиента будет -ли обеспечиваться синхронное закрытие ipn и vpn-шлюзов, а при поступленни денег - соотв. синхронное открытие, или эта схема не будет работать вообще в принципе и нечего тратить время на эксперименты с этим ?