vop

Не факт.

У меня биллинг умеет управлять сервисами. Любыми сервисами. Какие только в голову придут. Реально, написать управляющий скрипт под проброс портов через dst nat и отладить его - неторопясь с перекуром, часок другой. Тут вопрос в другом - переход на другой биллинг - это смена философии, что само по себе не просто. Поэтому ради одной фишки вряд ли стоит заморачиваться.

У себя бы я оформил это в качестве дополнительной услуги с управлением и соответствующим тарифным определением.

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

По правильному - никак. По не очень правильному - редиректить на свой https. При этом, если клиент пробьется через кучу варнингов, он узнает причину недопуска.

А при чем тут nodeny?

Rewrite в апаче - достаточно затратная функция, и для простых ситуаций лучше использовать 404 ошибку в .htaccess. ErrorDocument 401 /index.html Кстати, можно отправлять и на другой апач, например, на страницу биллинга с напоминалкой.

Для кого?

Еще проще - абонент сам выбирает тариф "пауза" с 1-го числа следующего месяца, как и любой другой тариф. Платит 10 гриве. Не более 2 месяцев в году. В этом случае неделя паузы оплачивается по полному тарифу. Как говорится - снял депозит досрочно - потерял проценты.

Кожемякину просто не спится, как хочется перед выборами за оппонентами последить.

Начисление ежедневное, расчет - в 0 часов 1-го числа. А пополняют пусть, как хотят. При блокировке - открытие при превышении лимита. При заморозке - при превышении порога, равного либо суточной абонеплате, либо месячной, в зависимости от условий.

Тогда, может проще разогнать его?

Если адрес gateway будет попадать в маску не основного, а дополнительного адреса, то src будет дополнительный. Надо указывать прямо адрес src, либо в запросах, либо в таблице роутинга.

Указывать в запросах ip 3.0.0.1?

Как я уже говорил, последний ставил плагин 4 месяца назад - подключают. Они подключат кого угодно и как угодно, лишь бы подключить. И я уверен, что первый протокол будет работать всегда. Первый протокол точно так же позволяет передавать фамилию, адрес, телефон.

Запросто. Путем последовательных выборок по домам. Перечень домов провайдера не сложно взять у провайдера, из "карты покрытия". Если не делать поиск, например, по улице и номеру дома, какой смысл во втором протоколе? Фамилии у Привата и так есть по всем адресам. Для этого есть коммунальные службы, которые дают такую информацию.

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

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

У меня есть модуль привата в составе платежного интергатора. Но чекер есть не для всех биллингов. Какие просили, такие и делал. PS Чекер - это интерфейс между интегратором и биллингом/магазином/сервисом

У Привата, как минимум, две подсистемы пополнения счета. Одна через их систему, если не ошибаюсь, биплан (терминалы, кассы, Приват24). Вторая - мерчант, работает, как и все мерчанты, в т.ч. и LiqPay. Под пополнение один скрипт. Под мерчант - другой. Под LiqPay - третий.

никто его не отправлял Тогда откуда он узнал, что в терминале можно платить за ваши услуги? Вы не путайте два разных случая. Одно дело, когда он прочитал в договолре ваши банковские реквизиты, и самостоятельно выбрал банковский перевод/оплату. И другой случай он прочитал в подготовленной вами информации для абонента, в которой вы предлагаете ему воспользоваться сервисом пополнениясета через терминал.

Ключевой вопрос - кто отправил клиента в терминал, и на каком основании терминал(банк) выступает от вашего имени, предъявляя клиенту ваш логотип и название. После уяснения этих вещей вопрос ответственности сразу становится прозрачным.

Скорее, ip neigh add permanent PS На самом деле, отличие существенное ipset от permanent arp.

По поводу свапа можно написать так: .... ipset create liqpaynew [..... add to liqpaynew set ....] ipset swap liqpaynew liqpay ipset destroy liqpaynew ....

Подозреваю, что под помощью понимается показать команды. Не проблема. 1. Проверка изменения списка. .... /usr/local/bin/dig +short -f файл_1 | grep '\([[:digit:]]\{1,3\}\.\)\{3\}[[:digit:]]\{1,3\}' | sort > /path.to/iplist_new.dat # Compare lists if cmp -s /path.to/iplist_new.dat /path.to/iplist.dat ; then # nothing new rm /path.to/iplist_new.dat exit 0 fi # different - process mv /path.to/iplist_new.dat /path.to/iplist.dat cat /path.to/iplist.dat | xargs -L1 $ADD ....